Coding Style: Benennung von Parametern

[Jazzman_Marburg]

Hallo.

Klingt vielleicht ein wenig komisch, aber ich würde gern wissen wie ihr es mit der Benamsung von Variablen in folgenden Fall haltet:
Eine Prozedur hat viele Parameter, z.B. ein ganzes Dutzend (bitte kein Streit darüber, ob das sinvoll ist, oder das Schnittstellen klein sein sollten etc.). In der Prozedur selbst, sollen die Parameter nicht geändert werden, also werden 12 weitere Variablen in der Prozedur benötigt die mit den Werten der Eingangsparamter versorgt müssen.
Wie haltet ihr nun die Eingangsparameter von den internen (oder besser: lokalen) Variablen auseinander?
Schreibt ihr z.B. ein "prm_" vor jeden Eingangsparameter um diese Variable als "Eingangsparameter" zu kennezeichen?
Also in etwa:
procedure Tuwas(prm_Hoehe, prm_Breite: integer)
var
Hoehe, Breite: integer
begin
Hoehe := prm_Hoehe
Breite:= prm_Breite

Kann ja schon unübersichtlich werden, wenn wie gesagt, die Schnittstelle viele (z.T. lange) Variablennamen hat.
Auf der anderen Seite ist folgende Lösung ja auch nicht gerade sinnvoller:
procedure Tuwas(H, B: integer)
var
Hoehe, Breite: integer
begin
Hoehe := H
Breite:= B

Habt ihr da einen Tipp, wie man es macht, dass man a) die Dinger auseinanderhalten kann, aber sich auch nicht 'nen Wolf schreibt?

Danke & Gruß
Jazzman

[Furtbichler]

Es gibt Leute, die packen ein 'a' vor einen Parameter. Aber heutzutage braucht man das eigentlich nicht.

Wenn Du nämlich richtig sauber programmierst, hast du nur 0-4 Parameter und so kleine Prozeduren, das man sofort sieht, was Parameter ist und was nicht.

Wenn du Parameter kennzeichnen willst, tust du das dann auch für Prozeduren, Funktionen, Methoden, globale Variablen, lokale Variablen, Felder usw?

[himitsu]

Und ich würde es andersrum machen.
Die öffentlichen Schnittstellen bekommen eine ordentliche Benamung, also hier wären es die Parameter und nicht die lokalen Variablen.

Wenn sich der Typ der Parameter nicht ändert, dann kann man diese doch intern weiterbenutzen und muß keine sinnlose Kopie verwenden.


Ich weiß nicht, aber mit S finde ich den Namen irgendwie komisch. :gruebel:

[BUG]

Zitat:

Zitat von Jazzman_Marburg (Beitrag 1144349)

In der Prozedur selbst, sollen die Parameter nicht geändert werden

Wieso das denn?

[Lemmy]

Hi,

Übergabem erhalten ein großes A davor - da habe ich mich in langen Jahren an Delphi angeglichen. Innerhalb der Procedure gibt es dann lokale Variablen mit ungarischer Notation. Was ich aber nicht verstehe - wenn die Variablen intern nicht geändert werden sollen, warum diese dann kopieren? Spätestens hier würde ich mir echt überlegen ob das so korrekt ist was da abgeht...

Grüße

[BUG]

Zitat:

Zitat von Lemmy (Beitrag 1144355)

Was ich aber nicht verstehe - wenn die Variablen intern nicht geändert werden sollen, warum diese dann kopieren?

Selbst wenn sie verändert werden, sollte das sich nicht außerhalb der Funktion auswirken.
Das Einzige, was ich mir vorstellen kann, ist dass die unveränderten Werte nochmal in der Funktion benötigt werden :gruebel:

[implementation]

Wenn es eine öffentliche Methode ist, bekommen die Parameter bei mir in der Regel einen aussagekräftigen Namen und ein A davor. Bei internen schlamp ich öfter mal rum, und kürze so ab, dass ich es nur noch selbst verstehe (manchmal sogar das nicht mehr :oops:)
Variablen heißen bei mir eh meist sowas wie i, j, x, y, m, n, s, t, s1, s2, idx, str, dx, a3 und so 'nen Kram halt, und die verwende ich innerhalb der Methode auch gern für unterschiedliche Zwecke wieder.:mrgreen:

Achtung, nicht nachmachen, kann Augenkrebs verursachen! :stupid:

[s.h.a.r.k]

Ich halte es im Prinzip so, dass ich private Klassenvariablen mit F "markiere", also F also Präfix verwende, Beispiel FHeight, und bei Parametern (meistens) ein A voranstelle.

Ich muss hier allerdings dazu sagen, dass, nachdem ich neulich das Buch Clean Code (ISBN-13: 978-3826655487) gelesen habe, eher dazu tendieren würde das A wegzulassen! Das hat den Grund, dass ich in der Zwischenzeit dazu tendiere wesentlich kompaktere Klassen und Methoden zu programmieren, ebenso darauf achte, welche Namen ich für Methoden und Variable benutzt. Allein aufgrund dieses Programmierstils komme ich eigentlich nie in die Versuchung eine lokale Variable wie einen Parameter benennen zu wollen.

[Lemmy]

Zitat:

Zitat von BUG (Beitrag 1144356)

Zitat:

Zitat von Lemmy (Beitrag 1144355)

Was ich aber nicht verstehe - wenn die Variablen intern nicht geändert werden sollen, warum diese dann kopieren?

Selbst wenn sie verändert werden, sollte das sich nicht außerhalb der Funktion auswirken.
Das Einzige, was ich mir vorstellen kann, ist dass die unveränderten Werte nochmal in der Funktion benötigt werden :gruebel:

Hä? :shock: Wenn ich einen Parameter einer Procedure/Function intern verändern will, mit entsprechender nachhaltiger Wirkung, dann kommt ein VAR davor. wenn ich den innerhalb der Proc/Func nicht verändern will, kommt nix davon - dann kann man den zwar intern immer noch verändern ist aber schlechter Stil (finde ich). Um das zu vermeiden und die Speicher-Schiebereien zu beschleunigen kann man noch ein Const davor schreiben.

Ich verstehs einfach nicht - vielleicht liegts an der Uhrzeit - warum übergeb ich Parameter an eine Proc/Func ohne die Absicht diese zu verändern und kopiere die in lokale Variabeln (mit dem selben Namen) um diese doch zu verändern?

Wenn es darum ginge z.B. einen String auseinander zu nehmen in einer Schleife, könnte ich das noch ein winzig kleines Stück nachvollziehen - wobei der Arbeitsstring lokal in der Proc/Func definitiv anders heißt als der Übergabeparameter, einfach schon aus dem Grund weil da mit der Zeit einfach was anderes drin steht...

Grüße

[BUG]

Zitat:

Zitat von Lemmy (Beitrag 1144360)

Wenn ich einen Parameter einer Procedure/Function intern verändern will, mit entsprechender nachhaltiger Wirkung, dann kommt ein VAR davor. wenn ich den innerhalb der Proc/Func nicht verändern will, kommt nix davon - dann kann man den zwar intern immer noch verändern

Das meinte ich doch :mrgreen:

[hathor]

Benamsung von Parametern -> bitte ändern in: Benennung von Parametern

[Furtbichler]

Zitat:

Zitat von Lemmy (Beitrag 1144355)

...da habe ich mich in langen Jahren an Delphi angeglichen. Innerhalb der Procedure gibt es dann lokale Variablen mit ungarischer Notation.

Na entweder an Delphi anlehnen oder ungarisch, wobei letzteres ja wohl etwas angestaubt ist und heutzutage nicht mehr verwendet werden muss. Außer, man muss noch in C(++) programmieren

[s.h.a.r.k]

Zitat:

Zitat von Furtbichler (Beitrag 1144379)

Na entweder an Delphi anlehnen oder ungarisch, wobei letzteres ja wohl etwas angestaubt ist und heutzutage nicht mehr verwendet werden muss.

Sehe ich ebenso -- die IDEs unterstützen den Programmierer hier derart viel, sodass dieses "Hilfskonstrukt" ruhig komplett wegfallen kann. Ebenso macht es das Refactoring evtl. etwas schwieriger, da man nun nicht mehr einfach den Typ ändern kann, sondern auch den Variablennamen mit ändern muss. Daneben sollten sinnvolle und aussagekräftige Variablen-/Methodennamen dahingehend unterstützend, dass man den Typen von Variablen bzw. Resultate von Funktionen anhand des Kontextes erraten können sollte -- klar ist, dass sowas nicht zu 100% möglich ist, aber durchaus in der Mehrzahl der Fälle funktionieren sollte.

[Lemmy]

@furchtbichler/Shark: 100%ige Zustimmung. Blöd wenn man in gewachsene Strukturen rein kommt und Sourcen aus 10-20 Mannjahren weiter pflegen muss mit 3-4 Kollegen. Da kann man halt schlicht nicht so wie man will und irgend wann sehen die privaten Sourcen halt genauso aus, weil das Hirn so einfacher und schneller denkt ;-)

[Jazzman_Marburg]

Beitragstitel geändert.

[Valle]

Zitat:

Zitat von Jazzman_Marburg (Beitrag 1144424)

Beitragstitel geändert.

Ne. ;-) Oben den ersten Beitrag editieren und dort auf erweitert klicken. (oder so)

Liebe Grüße,
Valentin

[Stevie]

Zitat:

Zitat von Furtbichler (Beitrag 1144351)

Es gibt Leute, die packen ein 'a' vor einen Parameter. Aber heutzutage braucht man das eigentlich nicht.

Wenn Du nämlich richtig sauber programmierst, hast du nur 0-4 Parameter und so kleine Prozeduren, das man sofort sieht, was Parameter ist und was nicht.

Wenn du Parameter kennzeichnen willst, tust du das dann auch für Prozeduren, Funktionen, Methoden, globale Variablen, lokale Variablen, Felder usw?

Zitat:

Zitat von s.h.a.r.k (Beitrag 1144358)

Ich halte es im Prinzip so, dass ich private Klassenvariablen mit F "markiere", also F also Präfix verwende, Beispiel FHeight, und bei Parametern (meistens) ein A voranstelle.

Ich muss hier allerdings dazu sagen, dass, nachdem ich neulich das Buch Clean Code (ISBN-13: 978-3826655487) gelesen habe, eher dazu tendieren würde das A wegzulassen! Das hat den Grund, dass ich in der Zwischenzeit dazu tendiere wesentlich kompaktere Klassen und Methoden zu programmieren, ebenso darauf achte, welche Namen ich für Methoden und Variable benutzt. Allein aufgrund dieses Programmierstils komme ich eigentlich nie in die Versuchung eine lokale Variable wie einen Parameter benennen zu wollen.

Ohne führendes A bei Parameternamen kann es aber sehr wohl eine Namensgleichheit mit Property geben, was auch bei Beachtung von Clean code für durchaus wahrscheinlich halte.

[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

Delphi-Quellcode:

FSomeProperty: TSomeType;

:P

[DeddyH]

Wieso P wie Pointer statt A wie Argument? :lol:

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

Zitat von Aphton (Beitrag 1144452)

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'"

:mrgreen:

[Stevie]

Zitat:

Zitat von implementation (Beitrag 1144457)

Zitat:

Zitat von Aphton (Beitrag 1144452)

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'"

:mrgreen:

:shock:
Nennst du deine Methoden nicht Method1 bis X? :lol:

[implementation]

Zitat:

Zitat von Stevie (Beitrag 1144458)

:shock:
Nennst du deine Methoden nicht Method1 bis X? :lol:

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

[Sir Rufo]

Zitat:

Zitat von Aphton (Beitrag 1144450)

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

Delphi-Quellcode:

procedure Foo( aValue : integer );

kann dann als "a Value" ("ein Wert") gesprochen werden.

Aus dem gleichen Grund werden teilweise BoolProperties auch ein "Is" vorangestellt.

Delphi-Quellcode:

property IsValid : Boolean;

[DeddyH]

Ich verstehe das zwar eigentlich auch so, aber dann müsste es doch konsequenterweise statt z.B. AOwner AnOwner heißen, oder sehe ich das falsch?

[Sir Rufo]

Zitat:

Zitat von DeddyH (Beitrag 1144462)

Ich verstehe das zwar eigentlich auch so, aber dann müsste es doch konsequenterweise statt z.B. AOwner AnOwner heißen, oder sehe ich das falsch?

grammatikalisch ja, aber so ist das halt mit Einzelschicksalen ;)

[Aphton]

Zitat:

Zitat von implementation (Beitrag 1144457)

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.

[Meflin]

Zitat:

Zitat von DeddyH (Beitrag 1144462)

Ich verstehe das zwar eigentlich auch so, aber dann müsste es doch konsequenterweise statt z.B. AOwner AnOwner heißen, oder sehe ich das falsch?

Keine Ahnung wie das in der Delphi-Welt ist, aber in anderen Sprachen ist das auch durchaus so üblich (z.B. bei Smalltalk, womit ich gerade mal wieder arbeite, und wovon ich jedes mal wieder aufs neue entzückt bin :love: )

[olee]

Wenn man sich das alles anschaut ist das eigentlich recht schlüssig (auch wenn es mir erst bei der Betrachtung dieses Themas zum ersten mal so richtig klar wurde):

F -> Field
P -> Pointer
A -> Argument (bzw. kann auch als "a" wie "a value" verstanden werden)

Delphi-Quellcode:

private
  fPoint : TPoint;
  procedure SetPoint(aPoint: TPoint);
  // unsinnig - aber mir fällt grad kein besseres Beispiel ein
  function SetPointByPointer(pPoint: PPoint);

[Tommiii]

Dass das 'F' für 'Feld' (bzw. im englischen 'field') steht, wäre mir nicht
so leicht in den Sinn gekommen (aber durchaus sinnvoll *g*)

Zitat:
"Weiterhin hat es sich durchgesetzt, die Variablen einer Klasse, Felder genannt, immer mit dem Buchstaben F zu beginnen. So werden Verwechselungen mit globalen und lokalen Variablen vermieden."

http://de.wikibooks.org/wiki/Program...ascal:_Klassen

LG

[himitsu]

Nja, im Prinzip gibt es ja keine festen Regeln, aber was mich immer ganz wuschig verrückt machtt,
ist

Delphi-Quellcode:

property Text: string read FGetText write FSetText;

.

G und S als Erstes erkenn ich schneller, also bei den Methodendeklarationen, aber vorallem denk ich wegen dem F meißt zuerst an das Feld und nicht an eine Methode.