Sprechende Namen aber Namen sehr lang

[Eisflamme]

Hi,

Wie macht ihr das, wenn die sprechenden Namen einfach zu lang werden, als dass sie gescheit sein können?

Ich meine, das fängt schon bei einer Map über Texturkoordinaten an. Das heißt dann TextureCoordinatesMap und davon der Iterator TextureCoordinatesMapIterator... Wenn der Konstant ist, wäre das der TextureCoordinatesMapConstIterator...

Ist das nicht irrsinnig? Wie vereinbart man sprechende Namen und die Tatsache, dass man irgendwo auch noch den rechten Rand des Bildschirms hat? Kürzt ihr ab, wenn ja, wo und was und ist das legitim?

Interessiert mich gerade Mal. :)

Viele Grütze

[Krishty]

Hi,

Hmmm, ich habe mich eigentlich an solche Namen gewöhnt. Problematisch wird das einzig und allein, wenn viele Dereferenzierungen hintereinander vorkommen:
MyResourcesByType[CurrentResourcesType][CurrentResourcesIndex].LastGeometry().BindTo(MyGPUsImmediateContext);
Sowas wird dann schlicht und einfach zu
auto & CurrentResource = MyResourcesByType[CurrentResourcesType][CurrentResourcesIndex];
CurrentResource.LastGeometry.BindTo(MyGPUsImmediateContext);
(auch, weil ich nicht weiß, wie gut der Compiler Dereferenzierungen innerhalb von Schleifen wegoptimieren kann). Größere Probleme habe ich durch verschachtelte Namespaces (siebte innere Klasse im dritten Namensbereich), da fängt der Code immer schon in der Mitte des Bildschirms an :(

Naja, und Informationen über Typ und c/v-Qualifier von Variablen gehören imo überhaupt nicht rein. Auf dein Beispiel übertragen: Iteratoren verhalten sich wie Zeiger, sie zeigen auf ein Objekt – ob das Objekt in einer Map, einem Vektor oder einfach so im RAM liegt, spielt bei der Benutzung keine Rolle. Also hieße eine Map, die Texturkoordinaten speichert und durch Strings wie "diffuse" addressiert, TextureCoordinatesByName und ihr Iterator ToCurrentTextureCoordinate, wobei das To einfach impliziert, dass man zwischen -> und . sinnvoll unterscheiden muss. Um this zu sparen und sinnvoll zwischen Memberfunktionen und Parametern zu unterscheiden benutze ich die Präfixe My und Its.

Wenn es hart auf hart kommt, greife ich schonmal auf Tex, Desc und Curr statt Texture, Description und Current zurück. Das ist aber ein Fall aus tausend.

Gruß, Ky

[TGGC]

Einen lokalen Iterator wuerde ich einfach nur it nennen. f'`8k


Gruß, TGGC (der kostenlose DMC Download)

[Krishty]

Warum eigentlich nicht i?

[Seraph]

Rechte Rand? Der ist weiiiit weg. :D Von daher benutze ich zumeist auch eher lange aussagekraeftige Namen. Ausnahmen sind u.U. lokale Variablen, z.B. wenn sie nur in den naechsten 2-3 Zeilen benutzt werden und sehr lang waeren. Einen lokalen Iterator wuerde ich wie TGGC einfach 'it' nennen, 'i' wuerde ich eher fuer echte numerische und fortzaehlende Variablen nutzen.

Fuer die Unterscheidung zwischen Membervariablen und Parametern/lokalen Variablen habe ich mir angewoehnt ein Underline '_' vor Membervariablen zu setzen. Ist imo kuerzer und offensichtlicher als 'My', aber letztendlich Geschmackssache.

[Krishty]

Einen lokalen Iterator wuerde ich wie TGGC einfach 'it' nennen, 'i' wuerde ich eher fuer echte numerische und fortzaehlende Variablen nutzen.

Soweit ich das verstanden habe, entstand i, j, k in Schleifen als Abkürzung für iterator (im Gegensatz zu „normalen“ Variablen, die a, b, c oder x, y, z genannt werden) – darum hat es mich schon immer stutzig gemacht, dass man zwischen i und it wählt und dass das viel mehr ein Missverständnis ist. Gibt es Online-Ressourcen zu Geschichte und Evolution dieses Schemas?

[joeydee]

Vorweg: ich tippe allein als Hobby, nicht im Team. Ich benutze eher abkürzende Namen wie oben genannt (z.B. currTexId statt currentTextureIdentifier), zur Sicherheit bei der Deklaration bzw. an wichtigen Stellen ein aussagekräftiger Kommentar, nicht nur was da passiert sondern auch womit. Dann geht das erfahrungsgemäß auch ganz gut wenn ich nach zwei Jahren mal wieder in den Code schaue. Für mich persönlich ist das besser und schneller lesbar als der ausgeschriebene Name.
i (j,k) sind bei mir generell nur lokale integer für (verschachtelte) Schleifen, oft beim Prototyping aus Faulheit. Sonst auch da lieber kurze hinweisende Namen.

[keepcoding]

Für Schleifenzähler verwende ich einfach sowas wie "i".
Ausserdem verwende ich noch immer die ungarische Notation, ist vllt etwas veraltet, aber ich finds halt immernoch sehr praktisch;) Dann brauchts auch kein "Iterator" am schluss, denn ein "i" am Anfang des Namens sagt ja schon, dass es sich um einen Zähler handelt.

"TextureCoordinatesMapIterator" würde bei mir also zu iTexCoordMap.
Der Übersichtlichkeit halber würde ich keine zu langen Variablennamen verwenden, aber dem Compiler ist das wahrscheinlich egal.

[Seraph]

@Krishty: Mit der Herkunft magst Du zwar Recht haben, aber ich unterscheide die Beiden weil man sie letztendlich auch verschieden zu benutzen hat.

[odenter]

Wenn man nur an einem Projekt (muss kein Spiel sein) arbeitet dann kann man abkürzen, weil man die ganze Zeit über im Thema ist.
Wenn Du aber öfter wechseln musst zwischen Projekten, dann sind sprechende Namen besser, weil Du nach 2 Jahren einfach nicht mehr im Thema bist und eben schneller wieder rein kommst.

[Aramis]

Was it vs i angeht, sehe ich es aehnlich wie Seraph: ein Iterator ist vom Konzept (wie auch vom ueblichen Pattern im Quellcode her!) her etwas anderes als ein Index, diese Unterscheidung geschickt in den Variablennamen einfließen zu lassen verringert meine Fehlerquote sowie den Denkaufwand. Damit will ich aber nicht sagen dass ich die ungarische Notation, egal welcher Auspraegung, befuerworte :-)

Ansonsten noch die (unvermeidbare, ueberspitzte) Ketzermeinung: „Sprechende” Namen sind unnoetig. Wer es nicht schafft die Bedeutung einer Variable in einer Form die, im Kontext der Deklaration, verstaendlich ist, in ein paar Zeichen hineinzupacken, hat unguenstig strukturiert.

IMHO ist die Namenswahl nur wichtig bei nichtlokalen Bezeichnern, d.h. in der C++–Welt Klassen-, Namespace-, Funktions- und Methodennamen.

[zwergmulch]

@Lange Namen nur bei nicht lokalen Bezeichnern: Sehe ich genauso. Mir geht es da dann oft so, dass ich lokale Variablen oft auch nach der ungarischen Notation benenne, aber nur das Präfix übernehme. Ein String heisst dann 's', ein Integer 'i' etc.
@Wenn immer in einem Thema abkürzen: Das sehe ich dann nicht so. Code lebt länger als man denkt und wenn es ein längeres Projekt ist (mit mehreren die mit arbeiten erst recht) sollte man zumindest Bezeichner, die nicht im Innenleben der Klasse sind, etwas beschreibender halten. Eventuell muss man dann nach längerer Zeit vlt. doch noch mal den Code verwenden und dann... ;)

Grüße zwergmulch

[Unknown GER]

Ich verwende in der Regel auch aussagekräftige Variablennamen, jedoch für Durchzählvariablen eigentlich nur i oder j usw. Ich finde es mit das Unübersichliste was mach machen kann, z. B. eine for-Schleife mit langen Namen vollzupacken. i für einen Index oder n für eine Anzahl ist total üblich, alleine schon aus der Mathematik. Wenn es ne mehrfach geschachtelte Schleife wird, kann man ja nen schönen Kommentar davor setzen, wo sie da wie durchzählt um was zu tun. Bei Iterartoren hatte ich bis jetzt fast noch nie eine geschachtelte Schleife. Dort nehme ich als Laufvariable iter und mindestens das .end() weise ich schon vorher einer Variablen end zu. Verblüffend wie übersichtlich auf einmal alles wird. ;)

[eXile]

Einen lokalen Iterator wuerde ich wie TGGC einfach 'it' nennen, 'i' wuerde ich eher fuer echte numerische und fortzaehlende Variablen nutzen.

Soweit ich das verstanden habe, entstand i, j, k in Schleifen als Abkürzung für iterator (im Gegensatz zu „normalen“ Variablen, die a, b, c oder x, y, z genannt werden) – darum hat es mich schon immer stutzig gemacht, dass man zwischen i und it wählt und dass das viel mehr ein Missverständnis ist. Gibt es Online-Ressourcen zu Geschichte und Evolution dieses Schemas?

Ich glaube, das mit den i, j, k in Schleifen wurde so schon unter FORTRAN gemacht. Wahrscheinlich (das ist zumindest meine Vermutung) liegt das einfach daran, dass FORTRAN so wie viele der frühen Programmiersprachen auch meistens von Mathematikern an Unis für numerische Berechnungen benutzt wurden. Dort werden eben solche Indizes schon seit fast Jahrhunderten benutzt. Das wurde dann so auch in die Programmiersprachen übernommen. Schließlich sind die Informatik-Institute erst im Laufe der Zeit aus den Mathematik-Instituten "entwachsen", und nicht plötzlich aus dem Boden geploppt.

Ich selber benutze übrigens eine genau gegenteilige Notation im Vergleich zu Krishty: Meine Variablennamen sind im Camel-Case, aber enthalten so gut wie immer Abkürzungen. Funktionsnamen auch. Keine ungarische Notation.

PS: Hat jemand von euch schon mal den von einem Mathematiker produzierten Code gesehen? Grausig, sage ich euch … :?

[Brainsmith]

@exile
Also... ich mag meinen Code.... *heul*

Ich bin aber auch ein CamelCaseFan.. gepaart mit m_ für member und b_ für übergebene Variablen als Präfix..

Nur in schleifen mach ich das nicht so.. int i=0 heißts da bei mir.. Die Variablen sind ja eh nach dem Schleifenaufruf wech

[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.)