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

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