Unsaubere Variablennamen

[m.fuchs]

Ich mach daraus mal ein neues Thema:

Und man sollte den Datentyp angeben......

Dies ist auch wichtig.

Code: Alles auswählen

var
  slCode:StringList;

ist einiges besser als

Code: Alles auswählen

var
  Code:StringList;

Nö ist es nicht. Dein sl-Prefix verwirrt den Leser nur. Und ist eine redundante Information. In Pascal sind Variablen typisiert, man muss also den Inhaltstyp nicht im Namen codieren.

[pluto]

Nö ist es nicht. Dein sl-Prefix verwirrt den Leser nur. Und ist eine redundante Information. In Pascal sind Variablen typisiert, man muss also den Inhaltstyp nicht im Namen codieren.

Das war ja mein Punkt, um den es mir ging: In JavaScript ist das, soweit ich weiß Freiwillig.

Was ja in vielen anderen Sprachen auch der Fall ist. Heftig finde ich das in PY.
Dort muss man zwar keine Datentypen angeben, aber wenn du ein Vergleich machst, musst du wissen was da drin ist um es entsprechend casten zu können.

[af0815]

Ich sage immer nur StyleGuide. Entweder einen persöhnlichen oder einen der Gruppe.

Ich meine damit sowas wie den von Borland (oder wie die jetzt gerade heissen) oder

http://wiki.freepascal.org/Coding_style
http://wiki.freepascal.org/DesignGuidelines
http://wiki.freepascal.org/GUI_design_guidelines
https://www.delphi-treff.de/object-pascal/styleguide/

Man muß mit dem ja nicht einig sein, dann sollte man aber seinen eigen machen.

Andreas

BTW: Wäre schön wenn es die für FreePascal/Lazarus mal zusammengefasst gäbe

[Michl]

BTW: Wäre schön wenn es die für FreePascal/Lazarus mal zusammengefasst gäbe

Gibt es doch. Sogar auf deutsch: http://wiki.freepascal.org/DesignGuidelines/de.

[af0815]

Gibt es doch. Sogar auf deutsch: http://wiki.freepascal.org/DesignGuidelines/de.

Hast du dir die Seite echt angesehen ? Vergleiche das mal mit dem von Borland/... bzw. dem aus dem Delphiforum. Dann wirst du verstehen was ich meine.

Andreas

[Michl]

...hat doch geklappt. Ich zitiere mal von hier: "Mit Wiki-Prinzip ist gemeint, dass eine Inhalte im Internet gemeinsam erarbeitet werden. Dabei ist es erlaubt und erwünscht, dass eine von einer Person begonnene Seite von anderen überarbeitet und ergänzt wird".

Und nun?

[af0815]

Und nun?

That's life Genau deswegen ist der Inhalt so

[compmgmt]

Nö ist es nicht. Dein sl-Prefix verwirrt den Leser nur. Und ist eine redundante Information. In Pascal sind Variablen typisiert, man muss also den Inhaltstyp nicht im Namen codieren.

Braucht man eigentlich nicht extra hinzuschreiben. Bei komplexen Funktionen mit vielen Variablen und vor allem Vergleichen wird es aber deutlich angenehmer, wenn man das später liest.

[m.fuchs]

Bei komplexen Funktionen mit vielen Variablen und vor allem Vergleichen wird es aber deutlich angenehmer, wenn man das später liest.

Wenn du komplexe Funktionen mit vielen Variablen hast, läuft eigentlich auch etwas falsch. Der Trick ist ja: kurze Funktionen (<= 20 Zeilen) mit wenig Variablen.

[kupferstecher]

Dein sl-Prefix verwirrt den Leser nur.

Das sehe ich auch so. Allerdings bezeichne ich Listen eigentlich immer als solche, z.B. "TriggeredItemsList". In diesem Fall wo es vermutlich eher um einen umgebrochenen Text ging, würde ich ihn "CodeLines" nennen. Das verdeutlicht schon stark das zugrundeliegende Format, was den Code einfach besser lesbar macht, ohne alle Typen von Listen zu kennen/zu unterscheiden.

Ansonsten bei Klassennamen natürlich immer ein vorangestelltes "T";
bei Objektvariablen zumindest dann ein vorangestelltes "f", wenn es ein zugehöriges Property gibt;
bei Übergabeparametern ein vorangestelltes "A", wenn die Bezeichnung recht unspeziefisch ist (AValue);
bei unspeziefischen temporären Variablen ein vorangestelltes "t" oder "tmp"; Wenn es eine temporäre Version einer nicht-temporären Variable ist, dann verwende ich oft eine Abkürzung des Namens, z:B. CodeLns für eine temporäre Kopie von CodeLines

Das sind jedoch meine eigenen Präferenzen~

[itjump]

Bei komplexen Funktionen mit vielen Variablen und vor allem Vergleichen wird es aber deutlich angenehmer, wenn man das später liest.

Wenn du komplexe Funktionen mit vielen Variablen hast, läuft eigentlich auch etwas falsch. Der Trick ist ja: kurze Funktionen (<= 20 Zeilen) mit wenig Variablen.

Sehe ich genauso. Abgesehen davon, dass unsauberen Code viel schlimmer ist, als eine unsauber benannte Variable. Ich für meinen Teil setzte zum Beispiel gerne für Zahlen z1, z2 usw. ein und bei Strings s1, s2 usw. was viele auch schon als unsauber betrachten. Jedoch dokumentiere ich über Kommentare was welche Variable macht und bei Code, den auch andere Lesen müssen benenne ich meine Variablen sinnvoller, sodass jeder gleich verstehen kann, welche Funktion die Variable hat.

[Mathias]

Was ich noch gerne der Übersicht zu liebe mache, Variablen-Gruppen welche zusammengehören in einen Record verbauen.
Und die meisten Sachen löse ich mit Klassen.

[Michl]

Abgesehen davon, dass unsauberen Code viel schlimmer ist, als eine unsauber benannte Variable.

Nein, das sind zwei Seiten einer Medaille.

Ich für meinen Teil setzte zum Beispiel gerne für Zahlen z1, z2 usw. ein und bei Strings s1, s2 usw. was viele auch schon als unsauber betrachten. Jedoch dokumentiere ich über Kommentare was welche Variable macht

Ich habe sicher auch schon viel verbrochen. Ein "i" (Integer) nehme ich auch gern als Zählervariable, ein "s", wenn nur ein String in einer Methode bearbeitet wird, geht sicher auch, dann hört das für mich seit einiger Zeit aber auch schon auf. Mit den Codetools (wenn man sich einmal an die paar Tastenkombinationen gewöhnt hat) hat man auch keinen wirklichen Geschwindigkeitsverlust beim Coden. Also ich stehe auf dieser Fetisch eines gut handformatierten Codes, mit gut verständlichen Bezeichnern und Methoden möglichst immer ein Stückchen kleiner, als das Editorfenster, sodaß ich diese mit einem mal überblicken kann und nicht scrollen muss.

Just my two cents.