A vor Variablen

[mkinzler]

Schaden tun aber 1 Zeichen Präfixe aber auch nicht

[rokli]

nun gewöhne ich mir - die mühsam angewöhnte - ungarische Notation ab ... und dann das!

[Dejan Vu]

Zitat von mkinzler:

Schaden tun aber 1 Zeichen Präfixe aber auch nicht

Schaden tun auch 30 Zeichen Präfixe nicht und Bezeichner a la 'i1', 'i99' etc. Der Lesbarkeit dienen sie nicht gerade. Da es bei der Programmierung jedoch um Lesbarkeit einerseits als auch um das *Weglassen* überflüssiger Dinge geht, sollte man das hier vielleicht auch beherzigen.

Ich lese gerne Code wie ein Buch:
1. 'if lCustomer.HasOpenInvoices'
vs.
2. 'if theCustomer.HasOpenInvoices'
vs.
3. 'if Customer.HasOpenInvoices'

Was liest sich flüssiger? 1000x 'l' im Geiste zu lesen ist 1000x ein geistiger Schluckauf. Muss nicht sein. Ob man nun 'the' hinzupackt, um es noch lesbarer zu machen, sei mal jedem selbst überlassen: Clean-Code-Jünger machen das (ein paar), ich nicht. Ich lasse auch 'Self' weg, andere bestehen darauf.

Übrigens wäre 'Self.Field' ein Ersatz für 'fField'

[Medium]

Das "l" für lokale Variablen spare ich mir auch, aber pscht (Das "a" in Argumenten nehme ich aber ganz gerne, besonders wegen der Englisch-Artikel-Lesbarkeit.)

[Der schöne Günther]

Ich habe mich mit Präfixen als letzte Rettung dafür, dass die Delphi-IDE so gut wie nichts formatieren kann auch nie anfreunden können.

Unter Eclipse habe ich immer ein LSD-Feuerwerk an Farben abgebrannt- Abstrakte Methode? Parameter? Lokale Variable? Feld? Klassenvariable? Ist der Typ ein Interface? Eine Implementierung? Alles konnte man anhand der Farben (und anderem) schneller sehen als man zwei Buchstaben lesen kann.

Mit der RAD Studio IDE bin ich größtenteils ganz zufrieden, aber Code Highlighting ist ja schon fast schlechter als Notepad++.

[himitsu]

aField, aClass, aGlobalVar ... da braucht man ja nur noch das A und es passt überall davor.

Und das mit den Farben geht im Delphi auch ... man braucht nur das passende Addon.

[Der schöne Günther]

Und welches ist das? Nichts gegen cnPack (es hilft schon sehr), aber im Endeffekt tut es auch nicht mehr, als ein paar Block-Schlüsselwörter wie begin..end oder try..finally bunt anzumalen.

(Und die Farben nur drüberzulegen. Dank ClearType sieht man den blauen Originaltext oft drunter durchschimmern)

[Dejan Vu]

Auch bei Farben gilt: Weniger ist mehr.
Wozu sollte ich mir bei

Delphi-Quellcode:

Type
  TMyClass = Class (TFoobar, ISomeInterface)
// oder ganz untypisch
  MyClass = Class (Foobar, ISomeInterface)

Die Klasse und das Interface unterschiedlich einfärben lassen. was soll das denn sonst sein? Das Interface wird zudem in jeder Sprache mit 'I' gepräfixt... Aber wer's gerne bunt mag. Soll ja wieder 'in' sein (retro).

Ich habe eine bessere Idee: Schreibt einfach übersichtlichen und leicht zu lesenden Code mit kleinen Methoden und verzichtet ganz auf globale Variablen der Konstanten.

[Der schöne Günther]

Oder Implementationen waren fett, Interfaces dünn. Oder es gab überhaupt keinen Unterschied. Zu lange her.

Solange ich nicht die Farben auf meinem persönlichen Bildschirm als Grund nehme um andere Dinge wie vernünftige Namensgebung schleifen lasse ist doch alles in Butter.

[jaenicke]

Zitat von Dejan Vu:

Und da wir uns -zumindest in modernen Programmiersprachen- auch von der ungarischen Notation und Ähnlichem verabschiedet haben

Ich benutze diese für visuelle Komponenten. Denn das ist ungemein praktisch, weil man nicht auf das Formular schauen muss um Komponenten zu finden.
Dass andere das nicht machen, sieht man an Fragen wie nach der parallelen Ansicht von Code und Quelltext...

So muss ich nur schreiben pnl, wenn ich ein Panel suche, und dann schauen welche es gibt. Wenn die dann ordentlich benannt sind, findet man das richtige Panel dann sofort. Wenn ich aber nicht weiß wie der Begriff anfängt, weil das nicht am Typ der Komponente festgemacht ist, muss ich viel länger suchen (oder eben zum Formular schalten).