Coding Style: Benennung von Parametern

[Medium]

Bei case-sensitiven Sprachen nehme ich gerne eine am Anfang klein Geschriebene (ansonsten weiterhin Camel-Case) Version der nachher mit dem Wert besetzten Properties, bzw. klein geschriebene sprechende Namen. Ungarisch kommt bei mir nur in Delphi, und nur bei Enums ins Haus. Fast alle IDEs bieten mehr als genug Unterstützung bei der Erkennung der Typen zum Zeitpunkt der Verwendung, dass das einfach über ist.
In Delphi verwende ich, weil nicht case-sensitive, ersatzweise den Property-/sprechenden Namen mit vorangestelltem a. Allerdings einem kleinen, da ich auch lokale Variablen klein schreibe, und Parameter den selben Scope haben. Damit grenzen sie sich noch etwas hübscher von Feldern, Properties und Methoden ab.

[Aphton]

Ne Frage - warum eig. ein A (wie Attribut?) anstatt P (wie Parameter!)

@Furchtbichler:
Private Felder einer Klasse werden ja mit F vermerkt ala
FSomeProperty: TSomeType;

[DeddyH]

Wieso P wie Pointer statt A wie Argument?

[Aphton]

Aber Parameter <> Argumente!
Im Rump einer Methode stehen Paramter, keine Argumente

... oder?

[DeddyH]

Zumindest Wikipedia spricht von Argumenten und nicht von Parametern.

[edit] Etwas exaktere Definition:

Zitat:

Die Begriffe Parameter oder Argument werden in diesem Kontext oft synonym verwendet, wobei sich 'Parameter' genau genommen auf die Funktionsdefinition bezieht, 'Argument' hingegen auf den tatsächlichen Aufruf.

Quelle: wieder Wikipedia [/edit]

[implementation]

Zitat von Aphton:

Aber Parameter <> Argumente!
Im Rump einer Methode stehen Paramter, keine Argumente

... oder?

Stimmt schon, aber man benennt Bezeichner ja nicht nach dem, was sie sind, sondern was sie enthalten.

Die Logik "Es ist ein Parameter, also P" ist wie: "Es ist ein String, also nenne ich ihn 'String'"
statt "Es enthält ein Argument, also A" -> "Es enthält den Namen, also nenne ich es 'Name'"

[Stevie]

Zitat von implementation:

Zitat von Aphton:

Aber Parameter <> Argumente!
Im Rump einer Methode stehen Paramter, keine Argumente

... oder?

Stimmt schon, aber man benennt Bezeichner ja nicht nach dem, was sie sind, sondern was sie enthalten.

Die Logik "Es ist ein Parameter, also P" ist wie: "Es ist ein String, also nenne ich ihn 'String'"
statt "Es enthält ein Argument, also A" -> "Es enthält den Namen, also nenne ich es 'Name'"

Nennst du deine Methoden nicht Method1 bis X?

[implementation]

Zitat von Stevie:

Nennst du deine Methoden nicht Method1 bis X?

Ich nenne in der Regel alle Methoden "Method", ohne Zahl, und überlade sie dann mit verschiedenen Signaturen.

[Aphton]

Zitat von implementation:

Stimmt schon, aber man benennt Bezeichner ja nicht nach dem, was sie sind, sondern was sie enthalten.

Echt?
Warum beginnen dann die Felder bei Klassen mit F wie zB.

Delphi-Quellcode:

TSomeClass = class
private
  FSomeProperty: TSomeType;
public
  property SomeProperty: TSomeType read FSomeProperty write FSomeProperty;
end;

[Edit]
Wenn der Bezeichner vom Typ String ist, benenne ich ihn ja nicht zwingendermaßen strSomeVariable. Je nach dem wo sie sich befindet, so wird sie auch benannt - bei Klassenfeldern eben mit F, als Parameter mit P (übrigens hat sich bei mir auch A eingebürget -.-') usw.
[/Edit]

Bei Methoden hingegen muss man das ja nicht machen, denn Methoden sind nur in Klassen enthalten. (Oder werden mittlerweile Prozeduren und Funktionen in Records auch Methoden genannt? xD)
Variablen dahingegen können an verschiedensten Orten definiert werden -> global, lokal, in Klassen, in Objekten/Records/..., in Funktionen/Prozeduren usw. usf.

[Sir Rufo]

Zitat von Aphton:

Ne Frage - warum eig. ein A (wie Attribut?) anstatt P (wie Parameter!)

Das a vor einem Parameter kommt nicht von Attribut, sondern verleiht dem Parameter etwas sprechendes - wenigstens im Englischen

procedure Foo( aValue : integer ); kann dann als "a Value" ("ein Wert") gesprochen werden.

Aus dem gleichen Grund werden teilweise BoolProperties auch ein "Is" vorangestellt.
property IsValid : Boolean;