A vor Variablen

[Bladefire]

Hallo,

hin und wieder treffe ich ein A vor Variablen in verschiedenen funktionen an. Ich würde gerne wissen was das heißt. Bzw. unter welchen Stichwort ich es googlen kann.

Lg Simon

[Namenloser]

Das A steht für „argument“. Ist einfach eine Konvention, die von manchen verwendet wird, genau wie das T für „type“ bei Klassen oder das F für „field“ bei Feldern.

[Aphton]

Ich glaube, dass es seinen Ursprung hier hat (Bsp zur Verdeutlichung)

Delphi-Quellcode:

type
  TPerson = class
  private
    Age: Integer
  public
    procedure setAge(AAge: Integer);
  end;

procedure TPerson.setAge(AAge: Integer):
begin
  Age := AAge;
end;

Bei dieser Zuweisung kann man kein Age := Age machen, da die Sichtbarkeit von innen nach außen hin aufgelöst wird (Funktionsparameter -> Klassenfelder -> Globale Variablen -> ...)

Ich find das aber eher unschön; da gibts auch eine einfache Lösung dafür:

Delphi-Quellcode:

procedure TPerson.setAge(Age: IntegeR);
begin
  Self.Age := Age;
end

[RWarnecke]

Namenloser ist da eher schon auf dem richtigen Pfad. Ich habe auch ein Fremdprojekt, welches ich übernommen habe. Da wurde auch alle Variablen so deklariert. Die Buchstaben können auch die Art der Variable ausdrücken, wie zum Beispiel Integer, String u.s.w.

Edit:
Ich glaube so etwas in der richtig suchst Du oder ? Link

[himitsu]

Zitat:

Zitat von RWarnecke (Beitrag 1265086)

Die Buchstaben können auch die Art der Variable ausdrücken, wie zum Beispiel Integer, String u.s.w.

Joar, wobei ich diese Art eher schlecht finde.

Es gibt mehrere Gründe für einen Prefix oder Suffix.
- Kennzeichnung der Quelle (Position)
- Kennzeichnung des Typs
- wer weiß was sonst noch

Aber so kann man es auch bei den Enums betrachten, was nun schöner ist.
- Prefix als Gruppierung/Kennzeichnung des Enum-Typs
- oder ohne Prefix und dafür mit Namespace


Bei Parametern lass' ich die Prefixe aber auch lieber weg, denn so heißen die Property genauso wie die zugehörigen Parameter.

[Sir Rufo]

Wenn man eine gewisse Namens-Konvention einhält, dann weiß man auf einen Blick, wo die Variablen herkommt, bzw. wo die hingehört:

Delphi-Quellcode:

// Typen fangen mit T an
TFoo = class
private
    // privates Klassen-Feld: hier gibt es nix definiertes, ich nehme dafür einen _
  class var
    _Value : string;
private
  // Felder einer Klasse beginnen mit einem F
  FValue : string;
  function GetValue : string;
public
  // Eine Eigenschaft wird so benannt, wie sie genannt wird ohne Prefix
  property Value : string read GetValue write FValue;

  // Argumente von Methoden beginnen mit einem A
  function GetSomething( const AValue : string ) : string;
end;

function TFoo.GetValue : string;
begin
  Result := '*' + FValue + '*';
end;    

function TFoo.GetSomething( const AValue : string ) : string;
var
  // Hier gibt es keine allgemein gültige Konvention
  // Meine Lokalen Variablen beginnen mit einem L 
  LValue : string;
begin

  LValue { Lokale Variable } := 
    Value   { Eigenschaft }  + 
    AValue  { Argument der Methode } + 
    FValue  { Feld der Klasse } + 
    _Value  { Klassen-Variable };

  Result := LValue;
end;

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

Felder und globale Variablen/Konstanten sind aber aus dem Blickfeld raus.



OK, außer man hat ein Plugin, welches die verschiedenen "Typen" farblich kennzeichnet. :stupid:

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

Delphi-Quellcode:

Procedure Save(aCustomer)

steht dort ja 'Save a customer'. In in der Konsequenz wäre dann

Delphi-Quellcode:

Procedure Summarize(anArgument)

grammatikalisch korrekt. Im Kontext von Clean Code, wo (beinahe) alles nur um Lesbarkeit geht, wird auch diskutiert, ob man nicht lieber

Delphi-Quellcode:

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:

Zitat von Medium (Beitrag 1265122)

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

Zitat von himitsu (Beitrag 1265090)

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

[rokli]

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

[Dejan Vu]

Zitat:

Zitat von mkinzler (Beitrag 1265138)

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' :kotz:

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

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

[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

Delphi-Quellcode:

begin..end

oder

Delphi-Quellcode:

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:

Zitat von Dejan Vu (Beitrag 1265100)

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

[himitsu]

Im Formdesigner F6 mit "Panel" und schon zeigt der mir auch alle Komponenten, welche als Typ oder Name "Panel" enthalten und bietet auch an ein neues TPanel hinzuzufügen. :stupid:

Und über die Struktur-Ansicht sieht man auch neben dem Quellcode was auf der Form liegt.
(solange man die Variable der Komponente nicht löscht, was möglich ist, wenn man vom Code aus nicht auf die Komponente zugreifen will)

[Dejan Vu]

Zitat:

Zitat von jaenicke (Beitrag 1265233)

Ich benutze diese für visuelle Komponenten. Denn das ist ungemein praktisch, weil man nicht auf das Formular schauen muss um Komponenten zu finden.

Hab ich in Delphi auch so gemacht und würde es nach einem Ausflug in andere Nomenklaturen auch wieder so machen.

Wie soll man denn ein Eingabefeld für den Vornamen noch nennen? VornameEdit? Das ginge mit VS und Resharper, weil er bei der Codecompletion bei 'Edit' auch diesen Bezeichner findet.

[Der schöne Günther]

Zitat:

Zitat von himitsu (Beitrag 1265247)

Im Formdesigner F6 mit "Panel" und schon zeigt der mir auch alle Komponenten, welche als Typ oder Name "Panel" enthalten

Oh. Wieder was gelernt :-D

[Dejan Vu]

Zitat:

Zitat von Der schöne Günther (Beitrag 1265259)

Zitat:

Zitat von himitsu (Beitrag 1265247)

Im Formdesigner F6 mit "Panel" und schon zeigt der mir auch alle Komponenten, welche als Typ oder Name "Panel" enthalten

Oh. Wieder was gelernt :-D

Hilft nur nicht viel bei der Code completion. Ansonsten braucht man das eigentlich nicht so.

[himitsu]

Zitat:

Zitat von Der schöne Günther (Beitrag 1265259)

Oh. Wieder was gelernt :-D

Solche Helper sollte man aber besser kennen.

Help Insight (am Besten zusammen mit Documentation Insight)
IDE Insight (da ist fast alles drin zu finden, vorallem auch die versteckten Optionen der Einstellungsfenster wie z.B. Tools>Optionen, in denen man nix mehr findet)
Code Completion
Live Templates
und viele nette Debug-Fensterchen


Aber ja, einen (besseren) Filter für die Codevervollständigung hab ich mir auch schon immer gewünscht :cry:

[Der schöne Günther]

Als wahres Delphi-Vollblut kenne ich das alles und nutze es natürlich voller Inbrunst. :smile2:

Mir war nur neu dass das F6-Teil auch weiß was auf dem derzeit angezeigten Formular abgeht.

[himitsu]

Man braucht einfach nur mal zu schauen welche Kategorien ohne Filter vorhanden sind.
Und wenn doch noch was fehlt, dann kann man das via OpenTools-API leicht hinzufügen.

Das ist ein Treeview mit den bekannten Tasten (Links, Rechts, Plus, Minus, Mal, Doppelklick), um die Kategorien aufzuklappen, wenn sie noch nicht alleine aufgegangen sind. :stupid:

[jaenicke]

Zitat:

Zitat von Dejan Vu (Beitrag 1265258)

Wie soll man denn ein Eingabefeld für den Vornamen noch nennen? VornameEdit? Das ginge mit VS und Resharper, weil er bei der Codecompletion bei 'Edit' auch diesen Bezeichner findet.

Mit dem CnPack geht das auch bei Delphi. ;-)
Man muss das nur so einstellen, dass es nix automatisch einfügt, denn leider kennen die Entwickler die moderneren Delphiversionen offenbar nicht so gut. Punkte in Unitnamen gehen da z.B. furchtbar schief.
Wenn man aber explizit mit Enter einfügt, ist die Ergänzung super.

[himitsu]

Zitat:

Zitat von jaenicke (Beitrag 1265543)

Punkte in Unitnamen gehen da z.B. furchtbar schief.

Vorallem wenn man nicht alle neuen Unitnamen auswendig kennt, dann kann man nach "Windows" lange in der Codevervollständigung rumsuchen, weil das Mistding immer nur am Wortanfang sucht, bzw. die Units nicht wenigstens ohne die Namespaces im Suchindex hält/findet. :wall:

[Phoenix]

Nochmal zur Historie:
Das ganze nennt sich "Ungarische Notation" bzw. "Hungarian Notation": http://de.wikipedia.org/wiki/Ungarische_Notation

Ist inzwischen aus der Mode gekommen, aber da das damals gang und gäbe war, zieht sich das in den damaligen Systemen natürlich durch wie ein roter Faden, und mit alten Konventionen zu brechen ist natürlich doof, wenn man auf einmal zwei unterschiedliche Notationen in einem Projekt hat.