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: