ZFX
ZFX Neu
Home
Community
Neueste Posts
Chat
FAQ
IOTW
Tutorials
Bücher
zfxCON
ZFXCE
Mathlib
ASSIMP
NES
Wir über uns
Impressum
Regeln
Suchen
Mitgliederliste
Membername:
Passwort:
Besucher:
4396333
Jetzt (Chat):
23 (0)
Mitglieder:
5239
Themen:
24223
Nachrichten:
234554
Neuestes Mitglied:
-insane-

ZFX
Coding-Foren
Sourcecode-Probleme
Stil
GepinntSeite: < 1 2
AutorThema
Sefiroth Offline
ZFX'ler


Registriert seit:
17.11.2002

Nordrhein-Westfalen
69490471
Re: StilNach oben.
Ich habe die Erfahrung gemacht, dass Präfixe für Typen und Klassen unglaublich stören, da sie absolut irrelevant sind. Sie verwirren mich als Leser, der in 99% der Fälle gar nicht wissen will, um welchen Datentyp es sich handelt (Beispiel: int oder float?). Ein wirklich gut durchdachtes System benutzt sowieso eine Menge typedefs, um Typen festzulegen. Hier ist ein Präfix für einen Typ sogar fehlerhaft.

Namensgebung für Variablen ist eine Kunst für sich. Das einzige, was ich benutze, ist ein Präfix für Membervariablen (m_). Ich habe die Erfahrung gemacht, dass dies hilft, Namenskonflikte z.B. im ctor zu vermeiden, und man immer sofort weiß, ob man sich auf Member oder auf lokale Variablen bezieht. Die explizite Schreibweise mit this-> ist noch unschöner und kann vergessen werden.

Nicht zuletzt ist die STL ein wunderschönes Beispiel für gute Lesbarkeit. Namen wie
stlVector oder szStreamSize sind viel hässlicher als vector und streamsize.
22.07.2004, 17:48:01 Uhr
Lex Offline
ZFX'ler


Registriert seit:
01.06.2003

Bayern
exan_@hotmail.com
Re: StilNach oben.
Hi...

also bei Klassen, Schnittstellen mache ich es immer so:

Code:
__interface material_sys_i
{};

class material_collector
    : public material_sys_i
{};


und bei Template-Klassen so:

Code:
template < class T > 
class TypeQueue_t
{};


Und noch diese:

Code:
m_ // Attribute
g_ // Global

pfn // Pointer zu fn
fn  // kein pointer 

nsp   // Namespace
area_ // Auch Namespace :D Aber nie vermischt
vcr   // Vektor
mtx   // Matrix
qtn   // Quaternion
tme   // Zeitwert
cpx   // Komplexe Zahl

f // float
b // bool
v // void
l // long
n // int
d // double
s // short

uf // unsigned float
ul // unsigned long
un // unsigned int
ud // unsigned double
us // unsigned short

usw...


soo.
Bye,
Lexander.



1 Mal gendert, zuletzt am 13.03.2005, 11:02:50 Uhr von Lex.
22.07.2004, 19:10:28 Uhr
Patrick Offline
ZFX'ler


Registriert seit:
25.02.2002

Deutschland
143040199
Re: StilNach oben.
mal so ne frage nebenbei, wo ist eigentlich der unterschied zwischen class und __interface?
22.07.2004, 19:34:42 Uhr
GermanGameDev
@uzingLG Offline
ZFX'ler


Registriert seit:
01.07.2003

Österreich
Re: StilNach oben.
Interface steht wohl für ein COM-Interface mit Referenzzähler und allem drum und dran.
22.07.2004, 19:51:55 Uhr
Pyramid-Network
Lex Offline
ZFX'ler


Registriert seit:
01.06.2003

Bayern
exan_@hotmail.com
Re: StilNach oben.
ahm...
wäre möglich

Aber im Grunde ist es doch bloß ein Type für eine Pure Abstract Class ?

Also dat:

Code:
__interface PureAbstract_i
{
public:
   HRESULT initiateWhatever( void );

};

// Ist das gleiche wie:
// ( interface ist das gleiche wie struct )

interface PureAbstract_i
{
public:
   virtual HRESULT initiateWhatever( void ) =0;

};

22.07.2004, 20:03:50 Uhr
LordHoto Offline
ZFX'ler


Registriert seit:
22.09.2002

Hessen
349986626
Re: StilNach oben.
Zitat von Cygon:

@LordHoto: Wäre auch eine Alternative, allerdings sollte man dann logischerweise die Members nicht mit Grossbuchstaben beginnen lassen, um Konflikte mit Symbolen vom Compiler und seiner Runtime library zu vermeiden


Mache ich auch nicht. Ich beginne z.B. auch Methodennamen klein. Und set*** und get*** gibts nicht da lieber ne public variable oder eine friend class.

MFG

LordHoto
22.07.2004, 21:04:44 Uhr
Sefiroth Offline
ZFX'ler


Registriert seit:
17.11.2002

Nordrhein-Westfalen
69490471
Re: StilNach oben.
Zitat:

nsp // Namespace

Du gibst namespace einen Präfix? Ist ja furchtbar.

Zitat:

Ich beginne z.B. auch Methodennamen klein. Und set*** und get*** gibts nicht da lieber ne public variable oder eine friend class.

public Variablen? Schon mal was von Invarianten gehört?
22.07.2004, 22:38:06 Uhr
Tactive Offline
ZFX'ler


Registriert seit:
21.07.2004

Niedersachsen
Re: StilNach oben.
@Cygon:

wie machst Du das eigendlich mit Member-Classes einer Klasse / Strukture. Bekommen die ein Prefix (m_ oder so?). Wie verhinderst Du überschneidungen bei den Variabeln.

Also sowas z.b.

Code:
class Foo
{
public:
  void createText(const char* message);

private:
  std::string message;
};


@TheWrite_GL:

Du bist ja ein noch schlimmerer Präfix-Fetischist als ich es ohnehin schon bin .....

Präfix für Namespaces, tze - fehlt nur noch das Du jede Klasse in eine eigenes Namespace packst

-
Tactive

23.07.2004, 00:53:56 Uhr
Cygon Offline
Programmier-Berater


Registriert seit:
18.08.2002

Hessen
4389513
Re: StilNach oben.
Deshalb nutze ich noch m_

Man könnte zwar genauso zwischen den gleichnamigen Variablen unterscheiden, indem man sich für die Klassenmembers angewöhnt
Code:
this->message = message;
Foo::message = message;

zu schreiben, aber hier bin ich bei m_ geblieben, weil's kürzer ist und von aussen sowieso nicht in Kontakt mit dem Verwender kommt.

Früher hatte ich ungarische und Präfixes, was dann so aussah:
Code:
class CTFXQueue { // C für Klasse und TFX statt namespace
  int m_nQueueSize; // n für int, 'Queue' ist redundant
};


-Markus-
23.07.2004, 07:30:51 Uhr
LunaticSystems
Tactive Offline
ZFX'ler


Registriert seit:
21.07.2004

Niedersachsen
Re: StilNach oben.
Habe jetzt Teile meines Quellcodes um- bzw. neugeschrieben unter vollständigen verzicht der ungarischen Notation und irgendwie muss ich Cygon zustimmen. Man fühlt sich wesentlich freier beim Programmieren.

Mir jedenfalls gefällt es besser und ich kann nur jedem raten dieses (letzten endes) kryptische Zeugs wegzulassen, naja jedenfalls sollte man es mal ausprobiert haben.

@Cygon:
Die m_'s habe ich auch gleich weggelassen

-
Tactive
26.07.2004, 15:48:40 Uhr
LeDom Offline
ZFX'ler


Registriert seit:
28.02.2005

Berlin
Re: StilNach oben.
Ich benutze auch keine Typen-Präfixe. Für Methoden die einen boolschen Wert zurück geben, nehme ich meistens ein 'is' davor:
bool isMyStuffActive();

Ich nutze 'Setters' und 'Getters'. Zum einem weiß man ja nie ob man da später nicht doch noch Abhängikeiten oder innere Funktionalität ändern möchte oder z.B. Event-Signale senden möchte etc.
Außerdem hilft es mir bei der Suche und Eingabe des Funktionsnamen (VisualAssist) da man mit is... get.. set... schonmal ne grobe Klassifierung der Methoden hat. Das ganze liest sich dann auch eher wie PseudoCode. Ich nutze auch ziemlich lange Bezeichnungen. Ist natürlich Luxus der durch Autocompletion, Functions-Deklarationen als Toolstips etc kommt.

Was ich noch manchmal nutze sind i_ (input), o_ (output)und io_ (input/output) präfixe für Funktions/Methoden Parameter. Aber nicht immer, öfters in Skriptsprachen.

Aus irgendeinem Grund bin ich auf m_ umgestiegen und es hat sich als vorteilhaft herausgestellt. Ich glaub es war auch für die autcompletion drop-down liste - da hat man dann alle Klassen Variablen dicht beinander, wenn man eine Methode der Klasse implementiert.

Ansonsten schreibe ich { grundsätzlich in die nächste Zeile. auf diese Weise erkennen ich viel schneller die Körper. Die andere Weise (mit weiterem Code in einer Zeile) wirkt auf mich chaotisch.

Sind halt persönliche Präferenzen. In Teams ist allerdings es wichtig, daß es einen einheitlichen Stil gibt - denke ich.
03.03.2005, 20:40:47 Uhr
Meine Website
yarin Offline
ZFX'ler


Registriert seit:
23.04.2003

Niedersachsen
Re: StilNach oben.
Meinen kompletten persönlichen interessiert hier wohl niemanden, deshalb nur das, was wohl kein anderer so macht:

Ich benutze die STL gern und viel. Da musste ich mir ein paar gleich bleibende Prefixe für die wichtigsten Klassen ausdenken. Gelandet bin ich jetzt bei dem immer gleichen ersten Buchstaben "s" für stl (Abk. einer Abk. - geil) und dem zweiten Buchstaben für die STL-Klasse. Beispiele:

Code:
std::vector m_svMeshes;
std::map m_smFonts;
stdext:hash_map m_smMaterials; // map oder hash_map macht in der Bedienung keinen Unterschied -> gleicher Prefix.


Ist natürlich nichts für Leute, die so schon was gegen Prefixe haben. Ich persönlich kann gar nicht mehr ohne und krieg jedes Mal Brechreiz wenn ich mir mal wieder Code von irgendeinem Linux-Hacker mit typischen Unix-Style (alles klein mit _ als Trenner, hauptsächlich einsilbige Variablennamen komplett ohne Prefixe) antun muss..
13.03.2005, 02:46:20 Uhr
malignate Offline
ZFX'ler


Registriert seit:
12.01.2004

Baden-Württemberg
204188265
Re: StilNach oben.
Bei mir sind einfach alles Objecte( auch normale Typen ) - in C++ UND C# - deshalb machen Präfixe keinen Sinn.
13.03.2005, 16:33:24 Uhr
BlackAnger Offline
ZFX'ler


Registriert seit:
08.07.2003

Baden-Württemberg
77321016
Re: StilNach oben.
Wie es scheint bin ich noch eine old-school-programmierer

Ich benutze immer noch Präfixe und das immer. All meine Variable haben m_ oder g_ Für Member bzw Globalvariable und danach folgt der Typ f oder b oder i...

Das sieht das so aus:

float m_fHeight;

ICh finde das sehr sehr praktisch, da ich dann sehe, was ich bei dieser Variablen zu beachten habe. Ausserdem, hat nahezu jeder entwickler einen eigenen Schreibstil mit dem er am besten arbeiten kann. Daher versteh ich jetzt nicht den sinn dieses Threads?!

Gibt es etwa hierfür normen?!
16.04.2005, 10:20:17 Uhr
Peter Müller Offline
ZFX'ler


Registriert seit:
25.09.2003

Bayern
Re: StilNach oben.
Zitat:
Gibt es etwa hierfür normen?!


Ja (auch wenn natuerlich niemand verpflichtet ist sich daran zu halten)
09.10.2005, 15:05:09 Uhr
RealArtFactory
Specialist Offline
ZFX'ler


Registriert seit:
29.08.2003

Nordrhein-Westfalen
99606527
Re: StilNach oben.
Also wenn ich sowas sehe wird mir echt schlecht. Das trägt ja wohl keineswegs zur Lesbarkeit des Codes bei:

Code:
if (statement) {
   code
} else {
   code
}

09.10.2005, 15:36:05 Uhr
BugSoft
Peter Müller Offline
ZFX'ler


Registriert seit:
25.09.2003

Bayern
Re: StilNach oben.
Wie gesagt geschmackssache. Aber der Sinn solcher Konventionen ist auch eher, dass der Code von verschiedenen Leuten gleich aussieht.

Denn wenn einer
Code:
if (statement)
 code;
else
 code
und der andere
Code:
if (statement) {
    code;
} elce {
    code;
}
schreibt, dann wird es erst unuebersichtich.

Und in den Java Coding Conventions steht auch, dass dieses _immer_ einfuegen von Blackklammern nach if, for, while, usw. dazu dient, dass man keinen Fehler macht, wenn man noch nachtraeglich etwas einfuegt
09.10.2005, 16:01:19 Uhr
RealArtFactory
Specialist Offline
ZFX'ler


Registriert seit:
29.08.2003

Nordrhein-Westfalen
99606527
Re: StilNach oben.
Naja die Begründung kann man sich ja irgendwie knicken. So super ist der Vorteil da auch nicht
09.10.2005, 17:26:19 Uhr
BugSoft
gNUKE Offline
ZFX'ler


Registriert seit:
11.10.2004

Rheinland Pfalz
193935048
Re: StilNach oben.
Also wenn hier alle ihren Senf dazu abgeben, muss ich das natürlich auch tun :

Früher habe ich in C++ auch Präfixe verwendet, aber sehr schnell ist mir bewusst geworden, dass damit der Quelltext eher unübersichtlicher wird - es sieht dann zwar richtig stylisch aus, ist aber nicht mehr zweckmäßig. Was mir auch sehr wichtig ist, ist in meinem Code eine gewisse Einheitlichkeit zu bewahren, was mit der Ungarischen Notation nicht wirklich möglich ist (da müsste man für jeden Typ ein Präfix haben und wenn man nur bestimmte Variablen be-Präfixt, kann man ja gleich alle weglassen).


Daher hab' ich mir das meiner Meinung nach Beste von den Java Coding Conventions und dem C++-Stil herausgepickt. Das sieht dann bei mir beispielsweise so aus:

Code:
namespace myspace
{
namespace utils
{

class String
{
private:
    int len;
    char* buffer;
    int siz;

public:
    String(char* string);
   ~String();

    int length() const;
    const char* toArray() const;
    bool equals(const String& string) const;
};

}
}

...

using namespace myspace::utils;

String str1 = String(\"bla\");
String str2 = String(\"bla\");

if (str1.equals(str2))
{
    // strings are equal
}
else
{
    // string are not equal
}
09.10.2005, 19:24:45 Uhr
Beliah Offline
ZFX'ler


Registriert seit:
28.11.2005

Niedersachsen
Re: StilNach oben.
Sorry das ich in einen etwas älteren Thread was schreibe aber ich wollte nur mal darauf hinweisen das 2 Arten der ungarischen Notation gibt, wobei die 2te eigentlich falsch ist.

Mehr kann man hier erfahren.

Ich benutz meistens auch keine Präfixe. Was ich mache ist z.b. bei 'get' 'set' und konstruktur setz ich ein 'arg' vor den Argument/Parameter namen damit man den nicht mit einer Variable der Klasse verwechselt.


ps.: Hallo

1 Mal gendert, zuletzt am 01.12.2005, 14:01:02 Uhr von Beliah.
01.12.2005, 13:58:43 Uhr
Devil Offline
ZFX'ler


Registriert seit:
26.07.2005

Baden-Württemberg
Re: StilNach oben.
Ehm und zu em Code da oben:
Code:
namespace myspace
{
    namespace utils
    {
        template 
        class String
        {
        public:
            typedef unsigned int size_type;
            typedef char_type value_type;

        private:
            size_type m_size;
            value_type* m_data;

        public:
            String(const value_type* ptr_source = TEXT(\"\"));
            ~String() { delete [] m_data; }
            String(String const& string);
            String& operator=(String const& string);

        public:
            const size_type length() const { return m_size; }
            const value_type* c_str() const { return m_data; }

        public:
            const bool compare(String const& string) const;

        public:
            const bool operator==(String const& rhs) const { return compare(rhs); }
        };
    }; // utils
}; // myspace

Hast nen paar mal nen const zu wenig drin, meiner Meinung nach und wenn du schon mit Zeigern arbeitest, darfst du die großen 3 direkt mal alle Implementieren.

Dann hab ich keinen String mit negativer Länger bisher gefunden. Du? Nen char* zu übergeben find ich immer gewagt und kann z.T. nur durch schäbbige Hacks wie bsw.:
Code:
std::vector<char> string(ptr_string, ptr_string + length + 1);
foo(&string[0]);
erreicht werden. Also auch hier ein const.

class ist automatisch erstmal private. Sonst musse struct nehmen, dann hasse automatisch public

Default-Konstruktor sollte man auch fast immer anbieten. Hier bietet sich aber an, den Konstruktor nicht explizit zu machen, da eine implizite Umwandlung durchaus gewünscht ist.

Bei deinem Beispiel:
Code:
{ // Neuer Scope, ob Funktion oder sonstwas!
    using namespace myspace::utils; // damit das nur local gilt!

    String string_first(\"first foo\"); // schön den normalen Konstruktor aufrufen ...
    String string_second(\"second bar\");

    if (string_first == string_second)
    {
        // strings are equal
    }
    else
    {
        // string are not equal
    }
} // close scope
... so

Bearbeitung
Ehm eine String-Klasse selber zu implementieren ist aber Schwachsin. Nja es sei denn man nutzt char_traits und hat somit nicht so die Probleme mit Zeichensätzen

2 Mal gendert, zuletzt am 01.08.2008, 19:39:04 Uhr von Devil.
01.08.2008, 14:41:42 Uhr
Merlin - A Legend awakes
Sven K. Offline
ZFX'ler


Registriert seit:
25.09.2004

Nordrhein-Westfalen
231112635
Re: StilNach oben.
Antwort auf einen ursprünglich 4 Jahre alten Thread, geil^^
01.08.2008, 15:24:45 Uhr
Trevo-Project
Unknown GER Offline
ZFX'ler


Registriert seit:
09.01.2003

Deutschland
Re: StilNach oben.
Da der Thread ohnehin gepinnt ist, geht das schon in Ordnung. ^^ Aber wenn er schon wieder auferstanden ist... was haltet ihr von pimpl's?

1 Mal gendert, zuletzt am 01.08.2008, 15:43:53 Uhr von Unknown GER.
01.08.2008, 15:43:30 Uhr
Helmut Offline
ZFX'ler


Registriert seit:
11.07.2002

Deutschland
280083044 helmut4242
Re: StilNach oben.
Also Pimpls (musste ermal googlen, was man damit meint) find ich eher unschön. Mit einem Interface kann man sowas glaube ich etwas eleganter lösen (setzt aber eine vtable voraus). Für maximale Performance würde ich ein paar Reserved Member zur Klasse packen. Wenn die dann doch ausgehen kann man immer noch auf Pimpls (komisches Wort) umsteigen, ohne die öffentlichen Header zu ändern

Ciao
01.08.2008, 16:03:29 Uhr
Bomber-Revolution
odenter Offline
ZFX'ler


Registriert seit:
13.12.2002

Bremen
Re: StilNach oben.
Ungarische Notation verwende ich nicht mehr, wird zu unübersichtlich und kann zu ganz seltsamen Namenkonstrukten führen.

Ich benutze lieber CamelCase
Ist jetzt c#
Code:
class CMeineKlasse {
  private Int32 meinZaehlerValue;
  public Int32 MeinZaehler {
    get { return meinZaehlerValue; }
    set { meinZaehlerValue = value; }
  }

  public void MachWas(Int32 wert) {
  }

  private string getString(string val) {
  }
}
15.12.2008, 15:23:35 Uhr
GepinntSeite: < 1 2


ZFX Community Software, Version 0.9.1
Copyright 2002-2003 by Steffen Engel