Sprechende Namen aber Namen sehr lang

[Unknown GER]

Ganz ehrlich? Wenn ich ne Bibliothek nutzen wollte und sehen würde, dass da jeder übergebenen Variable b_ vorangestellt wird, würd ich mich allein schon deswegen nach einer anderen Bibliothek umsehen. Da macht es doch keinen Spaß mehr zu programmieren. Ich finde man muss auch endlich mal bereit sein, sich von der IDE helfen zu lassen. Das ist ein Programmierstil, den ich vermuten würde, würde jemand mit VI als Editor arbeiten. ^^ Es ist wie mit Unicode oder 64 Bit... seit mindestens 10 Jahren verfügbar, aber jeder hat damit Probleme - das kanns nicht sein. :D Wenn ich ne fremde Klasse nutze, kann ich heute einfach sowas machen wie:

spaceShip->

spätestens jetzt oder nach Strg+Space bekomm ich ne schöne Liste der Methoden... und wenn da "setSpeed(float speed)" oder "setSpeed(float newSpeed)" steht, ist das ne rundere Sache als "setSpeed(float b_speed)". Warum sollte ich dem Nutzer sowas auferlegen, nur wenn ich meinen privaten Code in der Methode nicht lesen kann, wenn ich nicht b_ und m_ vor die Variablen setze? ^^ Das hat in einer Schnittstelle nichts zu verlieren. Noch dazu würde ich das erste mal versuchen dem b_ auf den Grund zu gehen weil ich denken würde, das will mir was wichtiges sagen, was für das Verständis wichtig wäre.

Was ich auch öfters sehe sind Grausamkeiten wie "spaceShip->setSpeed(MyUltraCoolGame::Core::SpeedType theSpeed). WTF? Da muss ich genau so nachsehen wie bei einem float in welcher Größenordnung derjenige nun die Geschwindigkeit will und was sich eigentlich hinter SpeedType verbirgt. Bei float wäre ich einfach von m/s ausgegangen wenn nichts dabeigestanden hätte und wüsste auch gleich noch dass ich eine Fließkommazahl angeben kann und nicht auf Integer beschränkt bin. :D

[Krishty]

Was ich auch öfters sehe sind Grausamkeiten wie "spaceShip->setSpeed(MyUltraCoolGame::Core::SpeedType theSpeed). WTF? Da muss ich genau so nachsehen wie bei einem float in welcher Größenordnung derjenige nun die Geschwindigkeit will und was sich eigentlich hinter SpeedType verbirgt. Bei float wäre ich einfach von m/s ausgegangen […]

Und genau das ist zu vermeiden. Was, wenn SpeedType kein einfaches typedef ist, sondern eine Revision später tatsächlich eine Klasse für eine physikalische Einheit darstellt, um das ganze mit Dimensionsanalyse auszustatten? In dem Fall zahlt es sich doppelt und dreifach aus, dass der User gezwungen wurde, setSpeed(CSpeed([hier zeigt dir IntelliSense den erwarteten Datentyp an]29000)); oder setSpeed(Meters(29000) / Seconds(1)); zu schreiben.

Dass der Bezeichner dann so sperrig ist und so tief in Namespaces vergraben wurde, ist in solchen Fällen aber natürlich immer kontraproduktiv, das stimmt wohl. Das Problem habe ich ohne C++0x’ template-Aliase auch, darum hieße der Parameter momentan noch TMakeSpeed<float>::CType statt einfach TSpeed<float>. Hoffentlich kommen die bald.

[kimmi]

Was sagt einem die folgende Zeile?

Code: Alles auswählen

spaceShip->setSpeed(MyUltraCoolGame::Core::SpeedType theSpeed). 

Daß man einen Core-Datentyp benutzt, um eine Eigenschaft einer speziellen Klasse zu beschreiben. Wenn nun noch SpaceShip in einem eigenen Namespace untergebracht wurde, sieht man durch dieses Konstrukt recht schnell: das ist doch Tünneff! Das folgende entspricht doch viel eher dem gewünschten Design:

Code: Alles auswählen

spaceShip->setSpeed(Game::SpeedType theSpeed)

Und da bin ich auch schon bei dem meiner Ansicht nach entscheidenen Punkt. Namen sollten aussagekräftig sein und das dahinterliegende Design beim Lesen aufzeigen. Ob man nun numIrgendwas oder NumberOfIrgendwas nimmt, ist da nicht so entscheidend. Zwar tippt man viel, aber für so etwas gibt es doch Copy&Paste. Was IMHO wichtig ist, ist die einfache Lesbarkeit des Codes. Ich habe im Job schon oft das Vergnügen gehabt, Legacy-Code zu warten ( momentan ein Framework mit zirka 1.7 Mio. zeilen Code ) und da helfen verständliche Namen ungemein. Und auch solche Namespaces und Klassenspezifische Typen sind da hilfreicher als man zunächst meint. Aber ich hab da auch länger für gebraucht, das so zu sehen.

Gruß Kimmi

[Brainsmith]

@unknownGer
das b_ vorneran mach ich, weil ich nur b_ tippen muss, um in der Methode die übergebene Variable(n) zu bekommen. Ist also nicht nach außen gedacht gewesen.. sondern für den, der die Methode implementiert..
Für mich macht das sehr wohl Sinn.. Aber ich hab in den meisten Fällen auch bisher in meinen eigenen Projekten geschrieben, wo kein anderer mitarbeitet.

Bei großen Projekten benutze ich die Namenskonvention, die dort allgemeingültig ist. Im jetzigen Fall nämlich keine.. ;-)

[zwergmulch]

Ich würde, wenn ich sowas mit den Präfixen für Parameter machen würde, dann aber Präfixe wie in oder out nehmen, damit man zwischen Rückgabewert und Input-Parameter unterscheiden kann.
Ist wahrscheinlich etwas informativer als nur b.
Wenn ich denn würde... ;-)

[Brainsmith]

Da könntest du durchaus recht haben.. Bisher habe ich allerdings keine out-Parameter in den Funktionen meines jetzigen Projekts.. Werde mir da allerdings mal Gedanken drüber machen. Macht durchaus Sinn.. :D

Und ich weiß nicht, ob das so angekommen ist, wie ich das tatsächlich meine. ich schreibe nicht nur einfach "b_".

Beispiel:

Code: Alles auswählen

void MuttiMachtEssen(float b_zeitInMinuten, char b_nameDesEssens []);

[Eisflamme]

Das Problem ist ja, dass gute Lesbarkeit und optimale Editierbarkeit zum Teil konkurrierend sind. Wenn man so was wie Core::Speed sieht, mag das ein wenig länger sein, als wenn da einfach float oder so steht, aber man weiß eben, dass es die vom Kern festgelegte Einheit der Geschwindigkeit ist. Ich finde, das ist dann einfach wie ein Glossar bei einer schriftlichen Arbeit, da muss sich jemand, der mit dem Projekt zu tun hat, eben einarbeiten. Hat er es erstmal getan, ist das aber kein Problem mehr und wenn man den Typ halt ändern will, weil man die Genauigkeit erhöhen möchte oder irgendwas wegen 64-Bit-System optimieren möchte etc. hat man es viel schneller.

Also mittlerweile versuche ich für alles Mögliche typedefs zu benutzen, wenn ich es häufiger nutze und eine gewisse Wahrscheinlichkeit besteht, dass sich der Typ ändern könnte. Bei int für ne Anzahl macht das meistens keinen Sinn imo, aber wenn ich mit float arbeite, ist das doch fast immer wünschenswert.

[Krishty]

[klugscheiß]

… aber man weiß eben, dass es die vom Kern festgelegte Einheit der Geschwindigkeit ist.

Typ! Nicht Einheit![/klugscheiß]

Bei int für ne Anzahl macht das meistens keinen Sinn imo

Das ist bei mir eine der ersten Stellen, wo ein typedef gelandet ist – weil eine Anzahl (im Sinne von: damit kann etwas indiziert oder adressiert werden, wie die Anzahl von Elementen in einem Array) auf 32-Bit Systemen 32 Bits groß ist und 64-Bit-Systemen 64, während Ganzzahlen für nicht-indizierende Berechnungen auf beiden Systemen 32 Bits groß sind. Außerdem haben Anzahlen immer unsigned zu sein ;) Ansonsten aber volle Zustimmung.

[Eisflamme]

Wayne 32bit vs 64bit betreffend Anzahl, wir nehmen da halt int und der ist doch auf 64-Bit-Systemen dann auch 64 Bit groß, richtig? Halt, Ganzzahlen sind immer 32 Bit? Jetzt musst du technischer werden, was ist ne Ganzzahl?

[Krishty]

int ist auf allen gängigen x86- und x64-Systemen 32 Bits groß. long int ist unter GCC x64 64 Bits groß, aber unter VC x64 weiterhin 32 – dort ist, wie auf GCC x64 und auf den entsprechenden x86-Plattformen, long long ein 64-Bit-Datentyp.

[Eisflamme]

nagut, hab noch nie x64 programmiert, daher... Dann mag ich auch hier typedefs :) long int sollten wir dann aber nicht verwenden, weils nicht klar is je nach compiler, rö?

[Krishty]

Dem Standard nach sind alle Typen mehr oder weniger Implementation-Defined ;) Aber dem Standard nach ist sizeof(char *) ja auch nicht gleich sizeof(int *).
Benutzt zum abzählen und adressieren am besten size_t, das ist auf allen Plattfornen so typedef'd, dass es optimal passt. Auch sollte (muss aber nicht) auf den meisten Plattformen int der schnellste ganzzahlige Typ sein. short und char haben sich heutzutage auch zu sehr etabliert, als dass sie auf nicht-exotischen Plattformen eine andere Größe als 8 und 16 Bits hätten.

Am sichersten fahrt ihr aber mit <cstdint> und den darin definierten uint8_t, uintptr_t etc.

[Eisflamme]

D.h. die du nutzt du wirklich in deinen Projekten?

[Biolunar]

[klugscheiß]
long long ist kein ISO C++ Datentyp.
[/klugscheiß]
Ich könnte nämlich oft genug das Kotzen kriegen, wenn ich versuche Fremdcode zu kompilieren, der aber durch tausend "long long"s mit tausend Fehlermeldungen abbricht. Da würde ich typedefs lieben: eine kleine Änderung am Code und aus tausend Fehlern werden Null. :)

Typen wie std::size_t verwende ich auch nur noch. Damals hab ich als unwissender mensch immer unsigned int genommen, bis ich auf einmal auf meinem x64 einen Segfault bei einer iteration von einem std::vector bekommen hab, weil sizeof (unsiged int) == 4, aber sizeof (std::vector<T>::size_type) == 8 war...
Aus Fehlern lernt man^^

[Krishty]

[klugscheiß]
long long ist kein ISO C++ Datentyp.
[/klugscheiß]
Ich könnte nämlich oft genug das Kotzen kriegen, wenn ich versuche Fremdcode zu kompilieren, der aber durch tausend "long long"s mit tausend Fehlermeldungen abbricht. Da würde ich typedefs lieben: eine kleine Änderung am Code und aus tausend Fehlern werden Null. :)

[klugscheiß]Unter C++0x schon :P[/klugscheiß] Ja, my bad – wenn man standardkonform bleiben will, gibt es momentan unter LLP per Definition keinen 64-Bit-Datentyp. Wie gesagt, stdint ftw.

D.h. die du nutzt du wirklich in deinen Projekten?

Ich kannte stdint noch nicht, als ich die Arbeit an meinem Framework begonnen hatte, darum benutze ich es nicht direkt. Ich benutze aber typedefs auf dieselben Typen wie in stdint, nur mit anderen Namen, damit sie besser zu meinen Naming Conventions passen. non-typedef'd Names kommen bei mir überhaupt nicht mehr vor – OpenFile(char ItsName[]) ist einfach nicht aussagekräftig in der Hinsicht, ob dort nur ASCII, ANSI oder UTF-8 erwartet wird. OpenFile(CUTF8Unit ItsName[]) schon. (Idealerweise sollte da natürlich eine eigene Klasse hin, aber ohne C++0x wäre die Entbehrung – keine String-Literale usw – einfach zu groß. Und wenn es denn kommt, vollzieht sich der Wechsel hoffentlich reibungslos.)

[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