A vor Variablen

[Dejan Vu]

In Zeiten einer modernen IDE, die mir über ein Rollover sagt, wo ein Bezeichner herkommt, kann man eigentlich komplett drauf verzichten, über Präfixe die Herkunft zu kodieren. Und da wir uns -zumindest in modernen Programmiersprachen- auch von der ungarischen Notation und Ähnlichem verabschiedet haben, kann man auch langsam den Rest in Angriff nehmen. Allerdings sind einige Präfixe und Konventionen sehr praktisch: ein 'f' für ein Feld z.B. Dann ist der backing store (das Feld) der Property 'Schießmichtot' immer 'fSchießmichtot' (oder 'F'?) und das ist dann einfach praktisch. Oder das 'I' für ein Interface, dann implementiert die Klasse 'Foobar' im Allgemeinen das Interface 'IFoobar'.

Bezüglich des 'A' habe ich auch Code gesehen, der das 'a' wie ein englisches 'ein' verwendet: Wenn man die Deklaration im Englischen liest: Procedure Save(aCustomer) steht dort ja 'Save a customer'. In in der Konsequenz wäre dann Procedure Summarize(anArgument) grammatikalisch korrekt. Im Kontext von Clean Code, wo (beinahe) alles nur um Lesbarkeit geht, wird auch diskutiert, ob man nicht lieber Procedure Save(theCustomer) verwenden sollte. Blöd ist das nicht. Sinnvoll auch imho nicht, aber wenigstens nicht hirnlos.

Eins noch: Jeder macht es, wie er will, nur eins ist wichtig: Im Team machen es alle gleich.

[Medium]

Diese Präfixe sind, zumindest in Delphi/Pascal, dem Umstand geschuldet, dass nicht zwischen Groß- und Kleinschreibung unterschieden wird. Unter Java und C# gilt meistens: Felder, Klassen und Methoden groß schreiben, Parameter und lokale Variablen klein. In Delphi heissen diese einbuchstabigen Präfixe meistens:

T: Type
I: Interface
L: Lokale Variable
F: Feld einer Klasse
A: Argument einer Methode, dass es dem Englischen Artikel entspricht ist eher glückliche Fügung
Methoden selbst bekommen meistens kein Präfix.

Alle Buchstaben werden mal groß und mal klein benutzt. Ich tendiere alles groß zu nutzen, ausser das "a" (weil ähnlich wie lokale Variablen in der Methode vom Scope her) und dem "l", um dem Kleinschreiben lokaler Variablen in anderen Sprachen zu entsprechen.

Beispiel:

Delphi-Quellcode:

type
  TSomething = class(TObject)
  private
    FSomeValue: Integer;
    procedure SetSomeValue(aValue: Integer);
  public
    property SomeValue: Integer read FSomeValue write SetSomeValue;
  end;

implementation

procedure TSomething.SetSomeValue(aValue: Integer);
var
  lCondition: Boolean;
begin
  lCondition := aValue > FSomeOtherValue;
  if lCondition then
    FSomeValue := aValue;
end;

Dadurch ist ohne viel im Code herumzusuchen recht schnell deutlich, welche Variable wo deklariert ist, und wo in etwa ihre Werte her kommen müssten.
Das ist aber alles nur Konvention unter Programmierern. Müssen muss das keiner so machen, es hat sich lediglich als Quasi-Standard etabliert. Auswirkungen auf den Code an sich hat das nicht, "nur" auf die Lesbar-, Wartbar- und Eindeutigkeit.

[Dejan Vu]

Zitat von Medium:

...A: Argument einer Methode, dass es dem Englischen Artikel entspricht ist eher glückliche Fügung

Sehe ich auch so.. aber es ist dann weitergesponnen worden.

'L' und 'A' würde ich sogar noch streichen. 'A' hab ich selber früher verwendet, aber 'L' noch nie und man braucht es nicht: Eine gut geschriebene Methode passt auf eine Bildschirmseite, macht genau eine Sache und ist daher übersichtlich genug, um den Scope komplett darzustellen.

Zitat von himitsu:

Nja, da man ja bekanntlich Funktionen nicht so groß machen soll, hat man somit die Lokalen und die Parameter immer im Blick und weiß somit wo sie her sind.

[mkinzler]

Schaden tun aber 1 Zeichen Präfixe aber auch nicht

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

[rokli]

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

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