Klasse: Überall "this->" vorkleben?

Eisflamme

SeppJ schrieb:

Begründung: Es wäre zwar nicht wirklich nötig, da aus dem Zusammenhang klar ist, was eine Typbezeichnung ist und was nicht, aber ein bisschen Groß- und Kleinschreibung ist angenehmer zu lesen und es erlaubt auch Konstrukte wie Ding ding; , die ich öfters benutze (denn oftmals ist keine weitere Beschreibung nötig, welches Ding genau ding ist).

In kenne ein paar C/C++ Projekte wo es sehr viele globale Variablen gibt und da ist es einfach schön anhand des Namens festzustellen ob diese global sind oder nicht.

Na ja, das Projekt leidet vermutlich unter anderen Problemen als Code-Konventionen, richtig?

Nathan

Shade Of Mine schrieb:

@Nathan:
das ist ein Problem mit der namensgebung. In den meisten Sprachen verwendet man getSize() statt size() bzw. gleich echte Properties.

Ja, es ist ein Problem der Namensgebung.
Gelöst habe ich das mit einem Unterstrich am Ende.

SeppJ schrieb:

Begründung: Es wäre zwar nicht wirklich nötig, da aus dem Zusammenhang klar ist, was eine Typbezeichnung ist und was nicht, aber ein bisschen Groß- und Kleinschreibung ist angenehmer zu lesen und es erlaubt auch Konstrukte wie Ding ding; , die ich öfters benutze (denn oftmals ist keine weitere Beschreibung nötig, welches Ding genau ding ist).

Ich würde da " ding d " schreiben.
Begründung: Code sieht einheitlich aus, weil ich viel Standardbibliothek+Boost nutze. Dass es eigene Klassen sind, stelle ich durch namespaces fest.
d ist ausserdem ein kürzerer Name als ding (und genauso vielsagend), was den Code übersichtlicher macht. Meine Funktionen sind in der Regel weniger als 10 Zeilen lang, da kennt man meistens alle Variablen.

Unterstriche verwende ich eigentlich wie Nathan und würde dann aber immer den Getter verwenden und nie direkt auf die Membervariable zugreifen.

SeppJ

Dann doch lieber gleich D d . Ach Quatsch. LCD-Monitore ziehen mehr Strom, wenn sie schwarze Pixel anzeigen. Da ich Schwarz auf Weiß programmiere (ökonomisch und ökologisch!) sollten also Bezeichner eine möglichst geringe Pixelzahl haben. '_" ist gut, 'i', 'I' und '1' auch. Richtig guter Code sollte also am besten so aussehen

_ I(_1 i)
{
 _ II;
 for(_ __ = i.i; _ != i.I; --i)   // Operator-- überladen, so dass er um 1 erhöht
   II -= *i;                      // Ebenso -=. Ist einfach weniger Pixel als +=.
 _I II;                           // Mit #define _I return
}

Nathan

rationaler coder schrieb:

SeppJ schrieb:

Begründung: Es wäre zwar nicht wirklich nötig, da aus dem Zusammenhang klar ist, was eine Typbezeichnung ist und was nicht, aber ein bisschen Groß- und Kleinschreibung ist angenehmer zu lesen und es erlaubt auch Konstrukte wie Ding ding; , die ich öfters benutze (denn oftmals ist keine weitere Beschreibung nötig, welches Ding genau ding ist).

Ich würde da " ding d " schreiben.
Begründung: Code sieht einheitlich aus, weil ich viel Standardbibliothek+Boost nutze. Dass es eigene Klassen sind, stelle ich durch namespaces fest.
d ist ausserdem ein kürzerer Name als ding (und genauso vielsagend), was den Code übersichtlicher macht. Meine Funktionen sind in der Regel weniger als 10 Zeilen lang, da kennt man meistens alle Variablen.

Unterstriche verwende ich eigentlich wie Nathan und würde dann aber immer den Getter verwenden und nie direkt auf die Membervariable zugreifen.

+1

SeppJ schrieb:

<getrolle>

Achso, du schreibst lieber

const MeinIntTypedef anfangsWertFuerDieSchleife = ZAHL_NULL;
const MeinIntTypedef exklusiverEndWertFuerDieSchleife = anfangsWertFuerDieSchleife + ZAHL_HUNDERT;
for (MeinIntTypedef temporaereZaehlvariableFuerDieseSchleife = anfangsWertFuerDieSchleife;
     temporaereZaehlvariableFuerDieseSchleife < exklusiverEndWertFuerDieSchleife; 
     inkrementiereMeinIntTypedef(temporaereZaehlvariableFuerDieseSchleife)

statt

for (int i=0; i<100; ++i)

Eisflamme

d? Ist nicht Dein Ernst. Zwei Klassen, die mit demselben Namen anfangen, führen dann ja zu zwei anderen Objekten. ding ist vielsagend, es zeigt, dass es eine Instanz der Ding-Klasse ist. d sagt nichts, da gehe ich von irgendeinem temporären double-Wert oder so aus.

Bin aber auch nicht sicher, ob das ernst gemeint war. Ich benutze einbuchstabige Bezeichner nur für Zählvariablen, bei denen die Funktion so eindeutig ist wie bei einer mathematischen Formel, sodass es in den 3-4 Zeilen dann wirklich unübersichtlich ist. Verschachtelt es sich, ist das aber schon nicht mehr angemessen, wie ich finde.

rationalerCoder:
Du bist wohl farbenblind oder wieso siehst Du nur schwarz/weiß? Ich stempel Dich Mal als Troll ab.

Jockelx

Naja, was ist denn Ding?
Ist Ding z.B. Point, dann hab ich schon 1000mal Point p; gesehen und mich nicht daran gestört.
Oder in Java ist es auch nicht ungewöhnlich, Objekte die nur in einem kleinen Scope leben, nach den groß geschriebenen Buchstaben zu benennen
(sowas wie FileInputStream fis)

SeppJ

Das ist doch ganz einfach zu lösen: Anstatt einem langen, beschreibenden Namen zu benutzen könnte man dem Kurznamen einfach ein kleines Präfix verpassen, das beschreibt, von welchem Typ die Variable ist. Wenn man Pp, ip und up schreibt, dann ist klar, dass jeweils ein Point, ein int und ein unsigned gemeint sind. Das gleiche sollte man der Ordnung halber am besten auch für Typnamen einführen: C für class, S für struct, t für typedef. Dieses Schema klingt ungeheuer vielversprechend .

Jockelx

Und "ding" ist dieser lange, beschreibende Name von dem du sprichst?

Eisflamme

Ich verstehe den Bezug SeppJs Argument zu Jockelx Beitrag nicht, da es nicht um Präfixe sondern Hauptbezeichner geht.

Also man kann schon p für Point benutzen... aber mit so was würde ich aufpassen. Für Wenigzeiler finde ich es wohl noch okay, aber so häufig kommen die ja auch nicht vor. Als Parameter für Funktionen finde ich es schon schlecht, weil die Funktionen damit ja etwas machen und das auch nicht immer direkt auf der Hand liegt. Und selbst wenn man es sich denken kann, macht man den Nutzen durch den Namen explizit.

Und einbuchstabige Bezeichner führen eben zum Namenskonflikt, wenn auch alternative Klassennamen in Frage kommen. Bei d denke ich zum Beispiel an double, bei p könnte man an einen Pointer denken. So was wie fis für FileInputStream finde ich wiederum okay, weil man da höchstens an eine Musiknote denkt, das führt wohl nicht zum Konflikt. Dann wiederum könnte der Code-Einseher sich trotzdem wundern. Da ist ein voller Bezeichner einfach klarer. Kurze Bezeichner sparen nur etwas Tipparbeit, aber da ich sowieso ding vorgeschlagen bekomme, sobald ich d eingebe, ist das Argument für mich nicht ziemlich schwach.

rationalerCoder:
Falls ich denke, dass es hilft, wähle ich übrigens wirklich Bezeichner, die so lang wie Deine sind und auch viel aussagen. Natürlich nicht für solche trivialen Fälle, aber in komplexeren Situationen kann das wirklich helfen.

Jockelx

Ich dachte es geht sowieso nur um sehr lokale Objekte. Natürlich ist das als Funktionsparameter Mist.
Aber ich halt mich da jetzt raus.
Glaube nicht, dass das zu was führt.

SeppJ

Jockelx schrieb:

Ich dachte es geht sowieso nur um sehr lokale Objekte. Natürlich ist das als Funktionsparameter Mist.
Aber ich halt mich da jetzt raus.
Glaube nicht, dass das zu was führt.

Ich habe bewusst etwas übertrieben. Natürlich ist folgendes ok:

for(Point p ...) 
 { 2-3 Zeilen}

Das wird aber ganz schnell schlimm, wenn es in der nächsten Eskalationsstufe zu

class Foo
{
  Point p, p2;
  double d;
  Ding dd;
};

wird. Das ist dann schon richtig übel. Wenn ich Code nicht nur für mich selber schreibe, benutze ich daher selbst bei Kleinstfunktionen halbwegs aussagekräftige Namen. Schon mit 4-6 Zeichen kann man Code um so vieles lesbarer machen:

for (int line ...)
 for (int column  ...)
// anstatt
for (int i ...)
 for (int j ...}

Schon besteht keine Gefahr mehr, dass diese Variablen jemals aus Unkenntnis falsch benutzt werden, egal wie lang der Code in 10 Jahren ist, nachdem er durch 15 Hände gewandert ist. Kosten: Praktisch 0. Tippgeschwindigkeit ist bei mir (und wohl jedem anderen) nicht der begrenzende Faktor beim Programmieren.

Nathan

Die einzigen Bezeichner, die ein Buchstabe lang sein können, sind immer noch x und y.

SeppJ schrieb:

Tippgeschwindigkeit ist bei mir (und wohl jedem anderen) nicht der begrenzende Faktor beim Programmieren.

Das stimmt zwar, aber Code mit kurzen Bezeichnern ist übersichtlicher. Schneller zu verstehen.

Ich finde deinen ökonomischen und ökologischen Code übersichtlicher wie meinen Buchstabensalat (ich habe dort eine Klammer weggelassen und es ist keinem aufgefallen).

Und logisch skaliert "d" nicht auf Funktionen mit mehreren Variablen. Aber dann verwende ich auch nicht "d", sondern einen sprechenden Namen (was "ding" ausschliest, weil genauso nichtssagend).

Für alles ausser lokalen Variablen in trivialen Funktionen, also insbesondere Member, sind einbuchstabige Namen Quatsch.

asc

rationaler coder schrieb:

SeppJ schrieb:

<getrolle>

Achso, du schreibst lieber
const MeinIntTypedef anfangsWertFuerDieSchleife = ZAHL_NULL;
///...
statt
for (int i=0; i<100; ++i)

Es gibt noch viel zwischen den Extremen. In vielen Fällen sind kurze, aber dennoch lesbare Bezeichner ausreichend. Wobei ich durchaus lange Bezeichner wähle wenn dies zur Beschreibung der Aufgabe dieser Variable nötig ist (da würde mir ein Präfix aber auch nichts helfen).

So finde ich die Aufgabe auch wesentlich wichtiger als deren Datentyp. Nehmen wir ein Beispiel: "std::size_t anzahlStudenten". Es ist hier eigentlich egal was für ein Typ diese Variable hat, zum lesen des Codes ist die Aufgabe viel wichtiger. Und die kann man hier direkt aus dem Namen ableiten. Und häufig sagt der Kontext in dem die Variable steht schon genügend aus um diese weiter abzukürzen (z.B. auf "anzahl").

Man liest Code wesentlich häufiger als man ihn schreibt. Und zum Lesen ist der Sinn, selten der Typ relevant (gute IDEs liefern einen ohnehin den Typ spätestens wenn man die Maus über den Namen hält). Und wenn man zudem versucht Funktionen eher klein zu halten, kann man den Typ auch notfalls recht schnell herausfinden wenn er wichtig ist.

Ganz davon abgesehen ändere ich eher den Datentyp als die Aufgabe einer Variable. Und nicht jede IDE hat Refactoring-Werkzeuge zum umbenennen... (leider nicht).

Nexus

Shade Of Mine schrieb:

Du erzeugst damit neue Scopes. Warum kennzeichnest du diese nicht?

Weil ich dadurch keinen Vorteil sehe. Es reicht, die Scopes kennzuzeichnen, deren Unterscheidung am meisten bringt: Member und lokale Variablen. Weil man keine this-> vergisst und direkt sieht, wenn der Objektstatus verändert wird. Zum Beispiel hatte ich auch schon Memberfunktionen, in denen gar keine Variable mit m -Präfix vorkommt. So sehe ich recht schnell, dass ich hier auch eine globale oder statische Funktion verwenden kann.

Nathan schrieb:

Die einzigen Bezeichner, die ein Buchstabe lang sein können, sind immer noch x und y.

Manchmal sind kurze Variablen aussagekräftig genug, weil sie im jeweiligen Bereich etabliert sind. Beispiele sind x, y, z, vx, t, phi, etc.

Ansonsten gilt: Wie kurz ein Bezeichner sein darf, hängt von dessen Lokalität ab. Je grösser der Scope, desto aussagekräftiger muss die Variable sein. Bei Lambda-Funktionen nehme ich ab und zu sehr kurze Bezeichner, um die kompakte Definition nicht unnötig aufzublähen. Schade, dass wir keine polymorphen Lambdas haben

Shade Of Mine

Warum haben dann Memberfunktionen keinen Prefix?
Gilt diese Argumentation denn nicht 1:1 auch fuer Funktionen?

otze

Nathan schrieb:

Die einzigen Bezeichner, die ein Buchstabe lang sein können, sind immer noch x und y.

Das könnn noch etliche mehr sein:

//implemented after Rosenberg et.all "A smart way to optimize the Bar problem", formula (16)
return a*b+C/phi*epsilon_sqrt(epsilon/exp(gamma));

in der Tat wäre es an der Stelle verwirrend, irgendwelche anderen Bezeichner als die im Paper zu verwenden.

Nathan

Ich habe mich wohl sehr unklar ausgedrückt.
Natürlich sind kleine Bezeichner in Ordnung, wenn der Kontext ihnen eine eindeutige Bezeichnung gibt.

Klasse: Überall &quot;this-&gt;&quot; vorkleben?

Klasse: Überall "this->" vorkleben?