Sprechende Namen aber Namen sehr lang

[Eisflamme]

D.h. native Datentypen wie float/double/int/short fallen alle raus und gibt es nur noch als typedefs? Und als Indexvariablen für [] gibt es dann std::size_t und für Zählvariablen stdint? Sonst noch irgendwelche wichtigen Dinge in der Hinsicht? :)

Ich weiß, ich lenk vom Ausgangsthema ab, aber... wayne?

[Krishty]

D.h. native Datentypen wie float/double/int/short fallen alle raus und gibt es nur noch als typedefs? Und als Indexvariablen für [] gibt es dann std::size_t und für Zählvariablen stdint?

Ja, genau. Alles darauf umzustellen ist eigentlich nicht wichtig, denn – seien wir ehrlich – wir werden unsere Engines nie auf eine Plattform portieren, wo alle ganzzahligen Datentypen 31 Bits lang sind (sowas gibt es und es ist die extremste Ausreizung des Standards). VC und GCC geben sich große Mühe, Code auf ewig kompatibel zu halten, weil es da draußen mehr Code gibt, bei dem ein Umstellen eines Datentyps fatal wäre, als wir im ganzen Leben sehen werden. Aber ich bin halt so ein ganz-oder-garnicht-Perfektionist – auch, wenn short int wohl die nächsten 30 Jahre lang 16 Bits groß bleiben wird ist mir allein, dass es anders aussieht als meine Zähler, Grund genug, es zu typedef’n :)

Sonst noch irgendwelche wichtigen Dinge in der Hinsicht? :)

Naja, all die typedefs haben zum Hintergrund, dass ich immer mal wieder mit dem Gedanken spiele, auf einen Schlag alle Datentypen in meinen Programmen durch Klassen auszutauschen … zwecks statischer Code-Analyse und so. Das ist aber jetzt wirklich hoch speziell und für 99,999 % ohne Nutzen: Wenn man sowas vorhat, muss man sich die Built-in-Datentypen irgendwo bei Seite legen und für zur Kompilierzeit initialisierte Werte benutzen, da C++ noch kein constexpr kennt. Also static MyInt const SomeVal = 0; ist nur so lange möglich, wie MyInt ein Built-In ist und man muss auf sowas wie static BuiltIn::MyInt const SomeVal = 0; ausweichen, falls man MyInt absehbar irgendwann durch was anderes ersetzen möchte.

[kimmi]

Na ja, ich würde mir das schon angewöhnen. Nicht, weil man seine eigene Engine mal portiert, sondern weil man irgend wann im Job einmal in die Verlegenheit kommt, Code auf solch eine Plattform portieren zu müssen. ich bin nämlich genau in einen solchen Fall gelaufen und mußte gefühlte 7 Tage auf einen Chefentwickler einreden, daß er sich endlich angewöhnt, size_t zu benutzen.

Gruß Kimmi

[Qrt]

Um wieder auf das eigentliche Thema zurück zu kommen.

Ich verwende derzeit (ich bin noch am experimentieren):
1. Project-Namespace: Mit 3-4 Buchstaben (QSS = Q's Studio Suite) um mich von meinen bisherigen Projekten abzuheben.
2. Kategorie-Namespace: Meist ausgeschrieben. z.B: QSS::Types, QSS::Core, QSS::Gui
3. Namespace: Versuch ich persönlich zu vermeiden.

Lokale Variablen:
Ausgeschrieben(mit Of): numberOfWidgets, index(for-Schleifen)
Parameter: mit einem vorangegangen Unterstrich: _parent, _count, _widget
Member-Variablen: mit einem schönen m_
Globale-Variablen: mit einem g_

Durch die Unterstriche kann ich die selben Namen nochmal verwenden: z.B: this->m_parent = _parent;

grüße qrt