Predeklaration mit namespace - Stilfrage

Dravere

Grüsse zusammen,

Ich bin mal wieder dabei meinen Programmierstil weiterzuentwickeln, vor allem wegen ein paar guten Argumenten von Shade Of Mine in einem anderen Thread. Ich glaube ich habe es nun endlich geschafft das C aus den Klassen wegzubekommen und sogar fast alle Prefixe, bis auf m_ (member) und g_ (global).

In diesem Zusammenhang habe ich mir auch sonst ein wenig meinen Code angeschaut und habe eine meiner Meinung nach momentan ziemlich hässliche Sache entdeckt und würde mal gerne nachfragen, wie ihr das macht.

Es geht um Predeklarationen von Klassen in mehrfachen namespaces. Momentan sieht das bei mir so aus:

////////////////////////////////////////////////////////
// Predeclaration

namespace xxx {

  class Z;

namespace yyy {
namespace zzz {

  class A;
  class B;
  class C;

} // zzz
} // yyy
} // xxx

namespace aaa {
namespace bbb {

  /* ... usw. ... */

} // bbb
} // aaa

// Und irgendwann kommt dann noch der namespace der eigentlichen Klasse und die Klasse selbst.

Das sieht irgendwie einfach nur hässlich aus.

Wie macht ihr solche Predeklarationen?

Grüssli

asc

Dravere schrieb:

Das sieht irgendwie einfach nur hässlich aus.

Wie macht ihr solche Predeklarationen?

Ähnlich, nur das ich wie bei jeden Scope einrücke. Die Kommentare bei den schließenden Namensräumen schenke ich mir, da diese eh durch die Einrückung selbsterklärend sind sind.

namespace xxx {
  class Z;

  namespace yyy {
    namespace zzz {
      class A;
      class B;
      class C;
    }
  }
}

namespace aaa {
  namespace bbb {
    // ... usw. ...
  }
}

cu André

Konrad Rudolph

Ich finde die Kommentare beim Namensbereich-Ende wichtig, ich „kollabiere“ sie aber, d.h. bei mir würde das dann so aussehen:

} } } // namespace xxx::yyy::zzz

Dravere

Danke ihr zwei.
Die Einrückungen wären zwar ganz schön, aber ich mache auch keine Einrückungen bei der Definition oder Deklaration. Das wäre ein Bruch. Ich könnte natürlich das andere anpassen, aber dann geht einem wertvoller Platz in der Breite verloren. Ich setze selber die Grenze bei 120 Zeichen fest, bereits mehr als die standardmässigen 80, aber habe auch so schon oft zu wenig Platz. Möchte da nicht noch mehr expandieren. Zudem viel schöner sieht es nicht aus ^^

Das mit dem kollabieren wäre noch eine Idee, damit es zumindest etwas kompakter aber trotzdem übersichtlich ist. Aber irgendwie immer noch nicht das Wahre. Nur was bleibt einem viel anderes übrig?

Hat sonst noch jemand eine Idee, bzw. macht es komplett anders?

Grüssli

asc

Dravere schrieb:

Das mit dem kollabieren wäre noch eine Idee, damit es zumindest etwas kompakter aber trotzdem übersichtlich ist. Aber irgendwie immer noch nicht das Wahre. Nur was bleibt einem viel anderes übrig?

Das kollabieren verwende ich selbst auch bei der eigentlichen Deklaration (s.u.). In sofern hast du recht mit der Breite. Doch ohne Einrückungen gehen meines Erachtens Informationen verloren. Anderseits habe ich dennoch keine Probleme mit der Breite (verwende selbst 82 als Breite) da ich trotz Schachtelungen auch Parameter umbreche etc:

// Vorwärtsdeklarationen wie oben
//...
// Nun eigentliches Element:
namespace Firmenname { namespace Bereich { namespace Unterbereich {

    class XYZ
    {
        public:
            XYZ();
            XYZ(                  // Ich habe mir inzwischen angewöhnt Parameter in jeweils
                XYZ const & rhs); // eigene Zeilen zu setzen, daher kein Breitenproblem ;)
            XYZ& operator=(
                XYZ const & rhs);
            ~XYZ();
    };

}}}

Dravere

Hmmm, ok, ich könnte natürlich auch eine eigene Zeile für Rückgabewert und co verwenden:

template<typename T>
void
set(std::string const& field,
    std::string const& value)
{
  /* ... */
}

Die parameter umbrechen tue ich auch, aber da gibt es manchmal auch Probleme:

void ein_längerer_funktionsname(aaa::bbb::cccc::KlassenName::EnumName wert);

Das sind bereits 76 Zeichen. Ist allerdings auch eher selten. Vielleicht sollte ich es auch ein wenig mit den Namespaces lassen, bzw. weniger verwenden.

Verwendet ihr eigentlich namespaces für die eigenen Klassen, wenn ihr eine executable entwickelt? Also keine Bibliothek?

Grüssli

asc

Dravere schrieb:

Das sind bereits 76 Zeichen. Ist allerdings auch eher selten. Vielleicht sollte ich es auch ein wenig mit den Namespaces lassen, bzw. weniger verwenden.

Verwendet ihr eigentlich namespaces für die eigenen Klassen, wenn ihr eine executable entwickelt? Also keine Bibliothek?

Man kann es mit Namensräumen auch übertreiben, aber verwenden tue ich diese schon. In der Regel begrenze ich mich dabei aber auf höchstens 3, im absoluten Extrem auf 4 Ebenen.

Beispielaufbau: <Firma/Projekt>::<Modul>::<Layer>::<Technologie>

z.B:

Simerion::Calendar::UI
 Simerion::Calendar::DL::Oracle

Bei allgemeineren Klassen/Funktionen auch mal nur 1 oder 2 Schachtelungen (Bei mir aber immer mindestens das Projekt).

cu André

Dravere

asc schrieb:

Beispielaufbau: <Firma/Projekt>::<Modul>::<Layer>::<Technologie>

Jo, so mache ich das eigentlich im allgemeinen auch:

// Zum Beispiel:
dsi::net::http

// dsi: Dracopien Software Industries
// net: Netzwerk/Internet
// http: HTTP-Layer

// Gibt dann auch:
dsi::net::ftp
dsi::net::irc
// usw.

// oder:
dsi::xml  // eXtended Markup Language
dsi::bdl  // Binary Data Language
dsi::util // Utilities

asc schrieb:

Bei allgemeineren Klassen/Funktionen auch mal nur 1 oder 2 Schachtelungen (Bei mir aber immer mindestens das Projekt).

Also auch bei auführbaren Projekten, wo die Klassen grundsätzlich nicht anderswo verwendet werden?

Grüssli

asc

Dravere schrieb:

asc schrieb:

Bei allgemeineren Klassen/Funktionen auch mal nur 1 oder 2 Schachtelungen (Bei mir aber immer mindestens das Projekt).

Also auch bei auführbaren Projekten, wo die Klassen grundsätzlich nicht anderswo verwendet werden?

Ich verwende privat immer und ohne Ausnahme (Abgesehen von int main() oder einer vergleichbaren Startroutine) mindestens den untersten Namensraum. Etwas das man immer einheitlich macht, vergisst man wenn es darauf ankommt nicht. Ich habe zwar in meinen Programmierstil auch die ein oder andere kleine Ausnahme, ich versuche aber grundsätzlich die Anzahl der Ausnahmen gegen 0 tendieren zu lassen (Beispielweise mache ich die öffnende Klammer im Regelfall in eine eigene Zeile, bei Funktionen die Einzeiler sind, mache ich die Ausnahme und die öffnende geschweifte Klammer steht in diesen Fall tatsächlich hinter dem Ende der Parameterliste).

cu André