Eine allgemeine Fragen zum Thema "Programmierstil"

Hallo Leute,

ich hoffe, ich löse jetzt keine Grundsatzdiskussion aus, aber ich habe ein paar Fragen zum Thema "Programmierstil". Ich möchte nur wissen, was allgemein als "guter Stil" angesehen wird bzw. als grober Stilfehler. Hauptsächlich möchte ich Dinge vermeiden, die "man nicht macht". Man ordnet ja z.B. eingebundene Header-Dateien alphabetisch, was man nicht zwingend müsste, aber empfohlen wird.

1.
Ist es sinnvoll, im Header kurze Funktionen auszuprogrammieren? Ich habe die meisten get und set Funktionen im Header programmiert, weil sie fast immer nur eine Zeile einnehmen. Dadurch wird die cpp-Datei übersichtlicher, weil sie nicht so viele Funktionen enthält. Ist das zu empfehlen, oder verwirrt das eher?

2.
Wo erklärt man Member-Variablen am sinnvollsten? Im Header, in der cpp-Datei ( wo sie ja meistens initialisiert werden ) oder an beiden Stellen (und dann mit dem gleichen Text) ? Sollte man Funktionen auch im Header beschreiben, oder reicht es in der cpp-Datei?

3.
In welcher Reihenfolge ordnet man Variablen an? Alphabetisch? Logisch zusammenhängend? Nach ihrem ersten Auftreten? Ganz egal?

4.
In welcher Reihenfolge ordnen man Funktionen an ( abgesehen von, public, private, public slots, private slots)?

Vielen Dank,

Hallo,
programmierstil ist immer so eine Sache. Ich bin z.B. ein absoluter verfechter der 80-Zeichen Regel, auch wenn diese nach meinem Gefühl von immer mehr Projekten gebrochen wird.

Zitat:

---

Zitat von Kirsche

1.
Ist es sinnvoll, im Header kurze Funktionen auszuprogrammieren? Ich habe die meisten get und set Funktionen im Header programmiert, weil sie fast immer nur eine Zeile einnehmen. Dadurch wird die cpp-Datei übersichtlicher, weil sie nicht so viele Funktionen enthält. Ist das zu empfehlen, oder verwirrt das eher?

---

schwer zu sagen, kommt natürlich auch auf die Gesammtgröße an. Aber ich bevorzuge eigentlich eine strikte Trennung:
header==Klassendefinition
cpp-Datei==ausprogrammierte Methoden.

Zitat:

---

2.
Wo erklärt man Member-Variablen am sinnvollsten? Im Header, in der cpp-Datei ( wo sie ja meistens initialisiert werden ) oder an beiden Stellen (und dann mit dem gleichen Text) ? Sollte man Funktionen auch im Header beschreiben, oder reicht es in der cpp-Datei?

---

also früher habe Variablen in der .h Datei kommentiert und Funktionen in der cpp Datei. Heute bevorzuge ich eher alles in der .h zu kommentieren. Natürlich mache ich auch noch Kommentare in der cpp Datei wenn es sinnvoll ist, aber die fallen dann eher kürzer aus und dienen eher als optische Hilfe wenn ich schnell durch-scrolle, dass ich sehe wann ein neuer Bereich bzw. Methoden zu einer neuen Berechnung/Funktionsweise kommen.
Für mich ist die .h datei der Ort wo ich mir einen Überblick über eine Klasse verschaffe, d.h. hier will ich sehen welche Variablen/Methoden es gibt und was sie genau machen.

Zitat:

---

3.
In welcher Reihenfolge ordnet man Variablen an? Alphabetisch? Logisch zusammenhängend? Nach ihrem ersten Auftreten? Ganz egal?

---

meistens logisch.

Zitat:

---

4.
In welcher Reihenfolge ordnen man Funktionen an ( abgesehen von, public, private, public slots, private slots)?

---

auch logisch, d.h. nach Funktion. Also wenn ich z.B. eine Methode habe die etwas berechnet und zwei Hilfsmethoden dabei aufruft. Dann kommt bei mir immer erst die Hauptmethode gefolgt von den Hilfmethoden (es können also auch public/private Methoden vermischt werden, mir ist der logische Zusammenhang wichtiger).
Ansonsen halt wie es mir logisch/passend erscheint, z.b. auch die load und save Methoden hintereinander usw.

Zitat:

---

Zitat von Kirsche

Man ordnet ja z.B. eingebundene Header-Dateien alphabetisch, was man nicht zwingend müsste, aber empfohlen wird.

---

Da gibt es dann auch noch Empfehlungen zuerst die projektspezifischen Includes zu machen und dann die allgemeineren.

also zB
lokale includes
project includes
library includes
system includes

Allerdings mach ich es immer andersrum :D

Zitat:

---

1.
Ist es sinnvoll, im Header kurze Funktionen auszuprogrammieren? Ich habe die meisten get und set Funktionen im Header programmiert, weil sie fast immer nur eine Zeile einnehmen. Dadurch wird die cpp-Datei übersichtlicher, weil sie nicht so viele Funktionen enthält. Ist das zu empfehlen, oder verwirrt das eher?

---

Das ist durchaus üblich und auch nicht per-se schlecht.
Sowas vermeidet man eher nur in Bibliotheken, weil sich dadurch Einschränkungen in der Erweiterbarkeit ergeben (zb: inlining wird aufgehoben)

Ich würde in diesem Fall dazu raten, es so zu machen wie du es gut findest, also wie du am schnellsten den relavanten Code findest solltest du ihn mal suchen.

Ich benutze inline Methoden nicht, wenn sich dadurch zusätzliche Includes im Header ergeben, also eine Forward Declaration auf einmal nicht mehr ausreicht.

Zitat:

---

2.
Wo erklärt man Member-Variablen am sinnvollsten? Im Header, in der cpp-Datei ( wo sie ja meistens initialisiert werden ) oder an beiden Stellen (und dann mit dem gleichen Text) ? Sollte man Funktionen auch im Header beschreiben, oder reicht es in der cpp-Datei?

---

Ich schließe mich BeS an: im Header.
Im Sourcefile sind Kommentare zur Erklärung von nicht so offensichtlichen Programmschritten gut.

Bei API Dokumentation im Header rate ich auf jeden Fall zu etablierten Syntaxvarianten, zB Doxygen Markup

Zitat:

---

3.
In welcher Reihenfolge ordnet man Variablen an? Alphabetisch? Logisch zusammenhängend? Nach ihrem ersten Auftreten? Ganz egal?

---

Definitiv logisch.

Zitat:

---

4.
In welcher Reihenfolge ordnen man Funktionen an ( abgesehen von, public, private, public slots, private slots)?

---

IMHO ansich egal, das einzige worauf ich zB achte ist die paarweise Anordnung von getter und setter Methoden.

Bei mir sieht die Grobstruktur meisten so aus
(zb für eine QObject Subklasse)

Code:

---

class Foo : public QObject
{
public:
    Foo(); // Konstruktoren
    Foo(int bar);
    virtual ~Foo(); // Danach Destruktor

    // restliche public Methoden, gefolgt von eventuellen Operatoren

signals: //falls vorhanden

public slots: // falls vorhanden

public: // variablen falls vorhanden

// das selbe für protected und private

private:
    // "Deaktivieren" von Copy Construktor und Zuweisungsoperator falls nötig
    // d.h. falls nicht weiter oben deklariert und implementiert
    // d.h. wenn man sie nur unebnutzbar machen möchte, ohne sie zu implementieren
};

---

Ciao,
_

Hallo BeS, hallo anda_skoa,

danke für die Antworten. Nun weiß ich etwas besser, wie ich meine Dateien gestalten werde.
Manches ist Geschmackssache, aber ich möchte grobe Stilbrüche ganz gerne vermeiden. Darum war es ganz hilfreich, mal zu hören, wie eure Ansichten dazu sind.

Schöne Grüße,

Ein paar Sachen die eventuell auch noch zum Thema beitragen stehen da drin: http://geosoft.no/development/cppstyle.html

Allerdings darfst du das nicht alles bierernst nehmen - insbesondere "11. Private class variables should have underscore suffix." finde ich grässlich ;)

MfG Peschmä

Hallo peschmae,

danke für den Link. Die Übersicht ist ziemlich gut.

Schöne Grüße,
Kirstin

Hi,
ich muss auch sagen, dass eine vernuenftige Variablen-Nameskonvention zum guten Stil gehoert.
Beispielsweise die Ungarische Notation.
Mehr dazu: http://www.uni-koblenz.de/~daniel/Na...ventionen.html

Das steigert auch enorm die Lesbarkeit des Codes.

gruss,
zrn

Finde ich nicht. Imo ist die ungarische Notation mit Präfixchaos ein Gräuel.

MfG Peschmä

Zitat:

---

Zitat von peschmae

Finde ich nicht. Imo ist die ungarische Notation mit Präfixchaos ein Gräuel.

---

Also ich verwende nur folgende Präfixe:

g_ für globale Variablen
m_ für Member Variablen

Der Typ wird eh vom Compiler geprüft ;)

Zitat:

---

Zitat von oracle2025

Also ich verwende nur folgende Präfixe:

g_ für globale Variablen
m_ für Member Variablen

Der Typ wird eh vom Compiler geprüft ;)

---

Mag sein, dass die ungarische Notation nicht das beste ist, es erhoeht aber auf jeden Fall die Lesbarkeit. Denn einer, der sich deinen Code anguckt, oracle, was bei OpenSource Projekten ja hoffentlich der Fall sein sollte, kann leicht den Ueberblick verlieren, ueber Typen usw...

@peschmae: hast recht, manche uebertreiben es ein bisschen :)