Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?

[KK27]

Hallo zusammen,

ich hab wieder ein Anliegen. Mein neuer Kollege auf der Arbeit hat mir ein bisschen von seinem Quellcode gezeigt und mir ist aufgefallen, dass alle seiner Parameter im hpp keine Namen haben. Also (bool, bool, int, int). Im Cpp haben diese natürlich Namen.

Seine Begründung dazu war, dass viele professionelle und bekannte Programmierer dies genau so machen. Überzeugt hat mich das gar nicht. Und als ihn fragte woher man wissen solle was man übergeben soll oder wenn man 2 Parameter mit dem gleichen Datentyp hat, meinte er man müsse nur in die Source(cpp) schauen.

Meiner Meinung nach sollte das hpp alles enthalten was für die Verwendung und Bedienung einer Klasse wissen muss. Wenn man die Funktionen und Member auch richtig dokumentiert, muss man die Namen der Parameter eh angeben.

Wie sieht ihr das oder hat seine Methode einen guten Vorteil, der mir einfach nicht ersichtlich ist?

[hustbaer]

Der einzige Vorteil davon der mir einfällt ist dass man Redundanz vermeidet, und dadurch auch vermeidet dass die beiden Stellen "auseinanderlaufen" wenn man Änderungen macht - also z.B. einen Parameter umbenennt. Allerdings gibt es mittlerweile genügend Tools die eine Warnung geben können wenn die Parameter im Headerfile anders heissen als im .cpp File.

Ich halte die Lesbarkeit des Headerfiles für viel viel wichtiger. Also ich würde ganz klar empfehlen den Parametern im Headerfile Namen zu geben. Und zwar genau die selben wie im .cpp File.

[omggg]

Mehrere Funktionen mit gleichen Parametern und gleichen Parameternamen sind ein Zeichen dafür, dass man die Funktionen zusammenfassen kann (sprich, die einzelnen zu wenig machen).

[KK27]

@omggg sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

Mehrere Funktionen mit gleichen Parametern und gleichen Parameternamen sind ein Zeichen dafür, dass man die Funktionen zusammenfassen kann (sprich, die einzelnen zu wenig machen).

Es ging mehr darum das die Parameter keinen Namen haben als die Effizienz. Es war nur ein Beispiel mit doppelten Datentypen um zu verdeutlichen, das es dann unklarer wird.

[Helmut.Jakoby]

@KK27
Ich persönlich nutze Parameter mit sprechenden Namen zur Dokumentation. Da ich alles "doxygen" Like dokumentiere und in der Doku nur die Header von Bedeutung sind, halte ich Parameter Namen sogar für unabdingbar.

[Jockelx]

@Helmut-Jakoby sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

in der Doku nur die Header von Bedeutung sind

Ich finde es ebenfalls gut alles im Header zu dokumentieren, aber dennoch der Richtigkeit wegen: doxgen ist es egal ob im header oder cpp dokumentiert wird.

[Helmut.Jakoby]

@Jockelx sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

@Helmut-Jakoby sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

in der Doku nur die Header von Bedeutung sind

Ich finde es ebenfalls gut alles im Header zu dokumentieren, aber dennoch der Richtigkeit wegen: doxgen ist es egal ob im header oder cpp dokumentiert wird.

Oh, danke, wusste ich nicht. Habe immer nur die Header in die *.dox eingebunden.

[Finnegan]

@Helmut-Jakoby sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

@Jockelx sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

@Helmut-Jakoby sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

in der Doku nur die Header von Bedeutung sind

Ich finde es ebenfalls gut alles im Header zu dokumentieren, aber dennoch der Richtigkeit wegen: doxgen ist es egal ob im header oder cpp dokumentiert wird.

Oh, danke, wusste ich nicht. Habe immer nur die Header in die *.dox eingebunden.

Ich würde sagen es macht sogar oft Sinn, die Doku im .cpp zu schreiben, besonders wenn da auch eine Beschreibung des Funktions-Verhaltens und des Algorithmus dabei ist. Wenn die Doku möglichst nah am relevanten Code ist, wird man sie vermutlich seltener vergessen anzupassen. Header kann man sich ja durchaus schonmal jahrelang nicht mehr ansehen und trotzdem ständig in den .cpp-Files hantieren.

[Helmut.Jakoby]

@Finnegan sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

@Helmut-Jakoby sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

@Jockelx sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

@Helmut-Jakoby sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

in der Doku nur die Header von Bedeutung sind

Ich finde es ebenfalls gut alles im Header zu dokumentieren, aber dennoch der Richtigkeit wegen: doxgen ist es egal ob im header oder cpp dokumentiert wird.

Oh, danke, wusste ich nicht. Habe immer nur die Header in die *.dox eingebunden.

Ich würde sagen es macht sogar oft Sinn, die Doku im .cpp zu schreiben, besonders wenn da auch eine Beschreibung des Funktions-Verhaltens und des Algorithmus dabei ist. Wenn die Doku möglichst nah am relevanten Code ist, wird man sie vermutlich seltener vergessen anzupassen. Header kann man sich ja durchaus schonmal jahrelang nicht mehr ansehen und trotzdem ständig in den .cpp-Files hantieren.

Das mit dem Anpassen der Doku bei Änderungen in der *.cpp ist einfacher, dass stimmt. Aber was ist, wenn ich die Sourcen gar nicht ausliefere, sondern z.B. eine DLL und die notwendigen Header?
In einem früheren Projekt wurde das Anpassen der Header in der QS überprüft, hat recht gut funktioniert. Wurde aber damals auch mit bezahlt .

[Finnegan]

@Helmut-Jakoby sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

@Finnegan sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

@Helmut-Jakoby sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

@Jockelx sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

@Helmut-Jakoby sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

in der Doku nur die Header von Bedeutung sind

Ich finde es ebenfalls gut alles im Header zu dokumentieren, aber dennoch der Richtigkeit wegen: doxgen ist es egal ob im header oder cpp dokumentiert wird.

Oh, danke, wusste ich nicht. Habe immer nur die Header in die *.dox eingebunden.

Ich würde sagen es macht sogar oft Sinn, die Doku im .cpp zu schreiben, besonders wenn da auch eine Beschreibung des Funktions-Verhaltens und des Algorithmus dabei ist. Wenn die Doku möglichst nah am relevanten Code ist, wird man sie vermutlich seltener vergessen anzupassen. Header kann man sich ja durchaus schonmal jahrelang nicht mehr ansehen und trotzdem ständig in den .cpp-Files hantieren.

Das mit dem Anpassen der Doku bei Änderungen in der *.cpp ist einfacher, dass stimmt. Aber was ist, wenn ich die Sourcen gar nicht ausliefere, sondern z.B. eine DLL und die notwendigen Header?

Ja, ich verstehe. Zwar kann man auch die generierte Doku mit ausliefern, aber es ist schon schön, wenn die IDE z.B. bei der Auto-Vervollständigung auch den Doku-Text mit anzeigen kann. Ich meine einige IDEs/IDE-Plugins machen das, wenn sie Doxygen-Kommentare im Quellcode erkennen.

[firefly]

@Finnegan sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

@Helmut-Jakoby sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

@Finnegan sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

@Helmut-Jakoby sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

@Jockelx sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

@Helmut-Jakoby sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

in der Doku nur die Header von Bedeutung sind

Ich finde es ebenfalls gut alles im Header zu dokumentieren, aber dennoch der Richtigkeit wegen: doxgen ist es egal ob im header oder cpp dokumentiert wird.

Oh, danke, wusste ich nicht. Habe immer nur die Header in die *.dox eingebunden.

Ich würde sagen es macht sogar oft Sinn, die Doku im .cpp zu schreiben, besonders wenn da auch eine Beschreibung des Funktions-Verhaltens und des Algorithmus dabei ist. Wenn die Doku möglichst nah am relevanten Code ist, wird man sie vermutlich seltener vergessen anzupassen. Header kann man sich ja durchaus schonmal jahrelang nicht mehr ansehen und trotzdem ständig in den .cpp-Files hantieren.

Das mit dem Anpassen der Doku bei Änderungen in der *.cpp ist einfacher, dass stimmt. Aber was ist, wenn ich die Sourcen gar nicht ausliefere, sondern z.B. eine DLL und die notwendigen Header?

Ja, ich verstehe. Zwar kann man auch die generierte Doku mit ausliefern, aber es ist schon schön, wenn die IDE z.B. bei der Auto-Vervollständigung auch den Doku-Text mit anzeigen kann. Ich meine einige IDEs/IDE-Plugins machen das, wenn sie Doxygen-Kommentare im Quellcode erkennen.

AFAIK muss dass dann aber nicht in der cpp datei sein. Da reicht es im Header.

[Finnegan]

@firefly sagte in Parameter von Funktionen und/oder Konstruktoren ohne Namen. Gut oder Schlecht?:

AFAIK muss dass dann aber nicht in der cpp datei sein. Da reicht es im Header.

Es ging ja darum, weshalb die Doku im Header doch sinnvoll sein kann, vor allem wenn man die .cpp-Dateien nicht mit ausliefert. Ich hatte ja empfohlen, die in der .cpp zu machen, weil die dann "näher" am relevanten Code ist.

[KK27]

Danke für die Antworten. Damit wäre meine Frage beanwortet.