Organisation von Code

Tut mir leid für die Noob-Frage, aber ich habe ein Problem meinen Code zu organisieren. Damit meine ich nun nicht die Organisation von Dateien, sondern der Code in der Datei. Es sieht alles so unübersichtlich aus. Einrückungen etc mache ich, aber wenn ich eine Datei nach einigen Wochen wieder öffen, dann erstmal "woah wall of text".
Hier mal als ein Beispiel ein Header von mir:
[cpp]
#ifndef _CREALWINDOW_H_
#define _CREALWINDOW_H_

#include <windows.h>
#include "MyProject.h"
#include "WindowSettings.h"

NAMESPACE_BEGIN

/*************************************************
Real Window-Class
*************************************************/
class CRealWindow
{
public:
explicit CRealWindow( CWindowSettings& settings );
~CRealWindow();
bool isRunning();

private:
/*--------- Members ---------*/
CWindowSettings m_settings;
HWND m_hwnd;
HINSTANCE m_instance;
bool m_running;

/*--------- Methods ---------/
bool createWindow();
void destroyWindow();
LRESULT CALLBACK WindowProc( HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam );
static LRESULT CALLBACK sWindowProc( HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam );
static CRealWindow GetObjectFromWindow(HWND hWnd);
};

NAMESPACE_END

#endif /* _CREALWINDOW_H_ */
[/code]

Wie organisiert Ihr euch damit Ihr den Überblick behaltet? Auch in der .cpp-Datei dann?
Danke für die Hilfe
lg

DeepCopy

cpp - Tags richtig gesetzt.

#ifndef _CREALWINDOW_H_
#define _CREALWINDOW_H_

#include <windows.h>
#include "MyProject.h"
#include "WindowSettings.h"

NAMESPACE_BEGIN

/*************************************************
Real Window-Class
*************************************************/
class CRealWindow
{
  public:
   explicit CRealWindow( CWindowSettings& settings );
   ~CRealWindow();
   bool isRunning();

  private:
   /*--------- Members ---------*/
   CWindowSettings m_settings;
   HWND m_hwnd;
   HINSTANCE m_instance;
   bool m_running;

   /*--------- Methods ---------*/
   bool createWindow();
   void destroyWindow();
   LRESULT CALLBACK WindowProc( HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam );
   static LRESULT CALLBACK sWindowProc( HWND hwnd, UINT uMsg, WPARAM wParam, LPARAM lParam );
   static CRealWindow* GetObjectFromWindow(HWND hWnd);
};

NAMESPACE_END
#endif /* _CREALWINDOW_H_ */

Kóyaánasqatsi

Die Kommentare sind völliger Quatsch. Das CRealWindow eine Klasse ist, sehe ich, also was bringt mir dann noch der Kommentar? Zeile 22 und 28 sind auch unnütz. Nicht beschreiben was es macht, sondern warum es was macht.

1337!!!

volkard

TheRookie26 schrieb:

Wie organisiert Ihr euch damit Ihr den Überblick behaltet?

So wie Du. Dein Code ist gut.
(Außer Kleinigkeiten wie unerlaubtem Includeguard, UN, /**/-Kommentaren und diesem NAMESPACE, aber die haben ja nix mit der Übersicht zu tun.)

TheRookie26 schrieb:

aber wenn ich eine Datei nach einigen Wochen wieder öffen, dann erstmal "woah wall of text".

Keine Regeln wie "Nach Jeder Deklaration eine Leerzeile" oder "Vor Jeder Deklaration drei Zeilen Kommentar, die die Deklaration beschreiben" oder "Beim Lesen eines Semikolons einen Schnaps trinken" können Dir helfen. Mußt halt flüssiger zu lesen lernen. Das es wird mit der Zeit von ganz allein besser.

It0101

Bei mir sieht es so ähnlich aus, wie bei DeepCopy.
Nur dass "private", "public" und "protected" bei mir nicht eingerückt werden.
Die Funktionen und Variablen sind immer 1 Tab ( 4 Zeichen ) eingerückt.
Wenn es viele Funktionen sind, mach ich das auch manchmal so:

inline void         Funktion1  ( int a, int b )        { return bla; }
       unsigned int Funktion2  ( int c );
       double       Funktion22 ( int d, int e, int f );

Also sozusagen formatiert geschrieben ( wobei die "inliner" eigentlich bei mir immer nebeneinander liegen. )

Aber das ist eine reine Frage der Code-Ästhetik.

David_pb

Kóyaánasqatsi schrieb:

Die Kommentare sind völliger Quatsch. Das CRealWindow eine Klasse ist, sehe ich, also was bringt mir dann noch der Kommentar? Zeile 22 und 28 sind auch unnütz. Nicht beschreiben was es macht, sondern warum es was macht.

1337!!!

Nein, die Kommentare dienen hier zum strukturieren, kein völliger Quatsch sondern sinnvoll.

pumuckl

David_pb schrieb:

Nein, die Kommentare dienen hier zum strukturieren, kein völliger Quatsch sondern sinnvoll.

Ein Absatz oder zur Not auch zwei wären ausreichend Struktur gewesen. Dass das was danch kommt ember bzw. Methoden sind ist deutlich zu sehen. Daher sind die Kommentare an sich überflüssig und lenken nur vom Wesentlichen ab. Genauso wie Kommentare, die keine zusätzliche Information liefern, z.B.:

// Funktion, die den Saldo berechnet
int BerechneSaldo()
{
  //int-Variable für den Saldo
  //der Salo ist am Anfang null.
  int saldo = 0;

  //rechne jeden einzelnen Posten hinzu
  //die Anzahl der Posten ist in anzahlPosten gespeichert
  for (int i = 0; i < anzahlPosten; ++i)
  {
    saldo += posten[i];
  }

  //saldo zurückgben
  return saldo;
}

Sowas ist völlig übeerflüssig.

Danke erstmal fürs korrigieren meiner Tags.

@volkard:

(Außer Kleinigkeiten wie unerlaubtem Includeguard, UN, /**/-Kommentaren und diesem NAMESPACE, aber die haben ja nix mit der Übersicht zu tun.)

Also das NAMESPACE wird ja ersetzt vom Präprozessor, das ist so definiert:

#define NAMESPACE_BEGIN namespace MyProject {
#define NAMESPACE_END   }

Aber was meinst du mit unerlaubtem Include-Guard und UN?
#pragma once geht ja nur mit VS2008 und ich möchte meinen Code portabel halten (soweit es geht).
lg

Registrierter Troll

TheRookie26 schrieb:

Also das NAMESPACE wird ja ersetzt vom Präprozessor, das ist so definiert:
#define NAMESPACE_BEGIN namespace MyProject {
#define NAMESPACE_END   }

Aber warum tust du das?

Aber was meinst du mit unerlaubtem Include-Guard

Bezeichner mit führendem Unterstrich sind für den Compiler reserviert.

pumuckl

TheRookie26 schrieb:

Also das NAMESPACE wird ja ersetzt vom Präprozessor, das ist so definiert:
#define NAMESPACE_BEGIN namespace MyProject {
#define NAMESPACE_END   }

Und zu welchem Zweck? Dadurch sparst du nichtmal Tipparbeit, geschweige denn dass der Code daruch lesbarer wird. Im Gegenteil, hinter dem #define kann sich im Ernstfall alles mögliche verstecken. Stattdessen solltest du das einfach gleich richtig hinschreiben.

zwutz

Registrierter Troll schrieb:

TheRookie26 schrieb:
Also das NAMESPACE wird ja ersetzt vom Präprozessor, das ist so definiert:
#define NAMESPACE_BEGIN namespace MyProject {
#define NAMESPACE_END   }
Aber warum tust du das?

warum nicht? Vor allem kann er sicher sein, dass es irgendwann nicht einen Namespace MyPorject gibt

pumuckl

Registrierter Troll schrieb:

Aber was meinst du mit unerlaubtem Include-Guard

Bezeichner mit führendem Unterstrich sind für den Compiler reserviert.

Um genauer zu sein: Mit führendem Unterstrich und folgendem Großbuchstaben. Und alles was doppelte Unterstriche enthält ist auch reserviert.

Walli

zwutz schrieb:

Registrierter Troll schrieb:
TheRookie26 schrieb:
Also das NAMESPACE wird ja ersetzt vom Präprozessor, das ist so definiert:
#define NAMESPACE_BEGIN namespace MyProject {
#define NAMESPACE_END   }
Aber warum tust du das?
warum nicht? Vor allem kann er sicher sein, dass es irgendwann nicht einen Namespace MyPorject gibt

Spaetestens wenn er etwas aus MyPorject benutzen will merkt er das.

Registrierter Troll

zwutz schrieb:

warum nicht?

Weil es eine Indirektion hinzufügt. Wenn ich den Code benutzen will, muss ich erst nachschlagen, was in dem Makro drinsteht.
Würde das Makro irgendwann geändert, wäre der Client-Code kaputt. Kommen weitere namespaces hinzu, ist der Makroname nicht mehr eindeutig, dann gibt es irgendwann BEGIN_NAMESPACE1 bis BEGIN_NAMESPACE17 .

pumuckl schrieb:

Um genauer zu sein: Mit führendem Unterstrich und folgendem Großbuchstaben.

Um noch genauer zu sein:

17.4.3.1.2 schrieb:

Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace.

David_pb

pumuckl schrieb:

David_pb schrieb:

Nein, die Kommentare dienen hier zum strukturieren, kein völliger Quatsch sondern sinnvoll.

Ein Absatz oder zur Not auch zwei wären ausreichend Struktur gewesen. Dass das was danch kommt ember bzw. Methoden sind ist deutlich zu sehen. Daher sind die Kommentare an sich überflüssig und lenken nur vom Wesentlichen ab. Genauso wie Kommentare, die keine zusätzliche Information liefern, z.B.:
// Funktion, die den Saldo berechnet
int BerechneSaldo()
{
  //int-Variable für den Saldo
  //der Salo ist am Anfang null.
  int saldo = 0;
 
  //rechne jeden einzelnen Posten hinzu
  //die Anzahl der Posten ist in anzahlPosten gespeichert
  for (int i = 0; i < anzahlPosten; ++i)
  {
    saldo += posten[i];
  }

  //saldo zurückgben
  return saldo;
}
Sowas ist völlig übeerflüssig.

Unsinn, die Kommentare werden hier ja nicht zur Kommentierung verwendet, sondern teilen das Interface logisch auf und dienen als Hinweis für (u.A.) andere Entwickler die Struktur beizubehalten und das ist keinenfalls überflüssig.

David_pb schrieb:

pumuckl schrieb:
David_pb schrieb:

Nein, die Kommentare dienen hier zum strukturieren, kein völliger Quatsch sondern sinnvoll.

Ein Absatz oder zur Not auch zwei wären ausreichend Struktur gewesen. Dass das was danch kommt ember bzw. Methoden sind ist deutlich zu sehen. Daher sind die Kommentare an sich überflüssig und lenken nur vom Wesentlichen ab. Genauso wie Kommentare, die keine zusätzliche Information liefern, z.B.:
// Funktion, die den Saldo berechnet
int BerechneSaldo()
{
  //int-Variable für den Saldo
  //der Salo ist am Anfang null.
  int saldo = 0;
 
  //rechne jeden einzelnen Posten hinzu
  //die Anzahl der Posten ist in anzahlPosten gespeichert
  for (int i = 0; i < anzahlPosten; ++i)
  {
    saldo += posten[i];
  }

  //saldo zurückgben
  return saldo;
}
Sowas ist völlig übeerflüssig.
Unsinn, die Kommentare werden hier ja nicht zur Kommentierung verwendet, sondern teilen das Interface logisch auf und dienen als Hinweis für (u.A.) andere Entwickler die Struktur beizubehalten und das ist keinenfalls überflüssig.

Kommentare sollen das beinhalten was nicht offensichtlich ist. So ein Quatsch wie

//saldo zurückgben
  return saldo;

hilft niemanden. Zuviele solcher Kommentare sind sogar ausgesprochen kontraproduktiv weil so der eine, wichtige KOmmentar unter hunderten Trivialkommentaren untergeht.

Kommentare sollen, wie schon andere gesagt haben, das WARUM kommentieren, nicht das WIE, denn das WIE ist idr bereits durch den Sourcecode selbst ausreichend sichtbar. Wenn der Sourcecode so unleserlich ist das er zusätzliche KOmmentare braucht ist etwas anderes faul. Beispiel:

int vXpr23iV;  // Variable um die Länge des Usernamens zu speichern

An der Stelle ist der Kommentar zwar tatsächlich notwendig im die Variable zu verstehen, aber auch nur weil die Benennung der Variablen schei ße ist.

int laengeUsername;

Gleiche Funktionalität, aber auch ohne Kommentar zu verstehen.

David_pb schrieb:

Unsinn, die Kommentare werden hier ja nicht zur Kommentierung verwendet, sondern teilen das Interface logisch auf und dienen als Hinweis für (u.A.) andere Entwickler die Struktur beizubehalten und das ist keinenfalls überflüssig.

Interface?!? Das sind Kommentare in einer Funktion, sie kommentieren die einzelnen Rechenschritte. Ich hab mal gelernt, dass Kommentare so weit wie möglich vermieden werden sollen, vielmehr sollen Namen (für Klassen/Methoden/Variablen) sprechend sein.
Außerdem finde ich es fragwürdig, wenn Kommentare dem Entwickler vorschreiben sollen, wie ein Algorithmus zu funktionieren hat.

In dem von dir zitierten Beispiel sind die Kommentare mehr als überflüssig.

Und die Unterteilung des OP kann man sich schenken, wenn man im Interface zu allererst Konstruktoren, dann den public Teil (für Verwendung der Klasse), dann protected (für Ableiten), dann private angibt. So sollte gewährleistet werden, dass jede Interessengrupee schnellstmöglichst ans Ziel gelangt. Rein ohne Kommentare.

pumuckl

David_pb schrieb:

Unsinn, die Kommentare werden hier ja nicht zur Kommentierung verwendet, sondern teilen das Interface logisch auf und dienen als Hinweis für (u.A.) andere Entwickler die Struktur beizubehalten und das ist keinenfalls überflüssig.

Und jeder Entwickler der sich den Code länger als eine Sekunde anschaut sieht die Unterteilung auch ohne Kommentar.

Icematix

Niemals C++-Sprachelemente wie "{" durch defines ersetzen.

David_pb

@ loks & toter hahn: Erstmal lesen und dann schreiben...

pumuckl schrieb:

David_pb schrieb:

Unsinn, die Kommentare werden hier ja nicht zur Kommentierung verwendet, sondern teilen das Interface logisch auf und dienen als Hinweis für (u.A.) andere Entwickler die Struktur beizubehalten und das ist keinenfalls überflüssig.

Und jeder Entwickler der sich den Code länger als eine Sekunde anschaut sieht die Unterteilung auch ohne Kommentar.

Erfahrungsgemäß ist das aber leider nicht der Fall.