Stil- und Namespace-Frage

7H3 N4C3R

Hi,

ich habe des öfteren in meinem aktuellen Projekt Code wie diesen hier gefunden:

Header:

namespace A
{
   class X
   {
      void X::f();
      ...
   };
}

Implementation:

using namespace A;

void X::f()
{
   ...
}

Und zwar genau, dass das X::f nicht direkt in den Namespace gelegt wird, sondern implizit über das using namespace A nachgeschaut wird. Finde ich persönlich erstmal gruselig - allerdings rutscht es auch durch eigentlich jeden Compiler und scheint erstmal grundsätzlich nicht falsch zu sein.

Ich suche nun fachliche/sprachliche Gründe dafür, warum man auch in der Implementation den Namespace A aufmachen sollte, anstatt ihn über ein using zu referenzieren.

Was mir einfällt ist:
Hilfsfunktionen wie operator< für eine Klasse X, wenn sie im cpp-File definiert werden, sind nicht mehr im selben Namespace wie die Klasse X - d.h. STL-Algorithmen können operator< nicht finden über ADL. Immerhin predigt Herr Meyers ja auch immer, alle Operatoren im selben Namespace wie die Klasse zu platzieren.

Das Gegenargument vom Kollegen:
Der Code muss durch den Namespace neu eingerückt werden und sieht "unschön" aus und ist bis auf Lookup-Spezialfälle übersichtlicher.

Was habt ihr noch als Argumente oder Gegenargumente anzubringen?

CStoll

Die Klasse X liegt (auch mit using) im Namensraum A - also solltest du auch ihre Methoden im Namensraum A implementieren (sonst besteht die Gefahr, daß der Linker sie nicht wiederfindet).

(wobei ich mir im Moment nichtmal sicher bin, ob diese using-Variante vom C++ Standard abgesichert wird)

PS: Das mit der Einrückung ist übrigens Geschmackssache

7H3 N4C3R

Ob es durch den Standard definitiv abgesichert ist oder nicht wäre natürlich sehr wichtig und interessant. Allerdings habe ich da keine Ahnung wo ich anfangen soll zu suchen, denn sonst sitze ich morgen noch hier und werfe Projektzeit für nix raus, obwohl momentan alles geht.

Natürlich ist die Einrückung Geschmackssache und für mich kein kräftiges Argument.

Linkerprobleme gab es noch keine und wir übersetzen auf 4 Plattformen mit 5 Compilern.

Konrad Rudolph

CStoll schrieb:

PS: Das mit der Einrückung ist übrigens Geschmackssache

Nicht nur. Es ist auch ganz einfach Sache der Praktikabilität. Drei Einrückungsebenen bevor man überhaupt beginnt, Code zu schreiben (Namensbereich, Klasse, Methode. Eventuell kommt noch der Sichtbarkeitsbereich hinzu, oder noch ein Namensbereich), ist reine Verschwendung, die teilweise teuer kosten kann. Wenn man guten Code schreibt, kann man dann nur noch 68 Zeichen benutzen -- und das ist, vor allem, wenn man vernünftige Methodennamen verwendet -- echt wenig.

Wenn man ein Buch schreibt, hat man bereits verloren.

Daher ist es durchaus sinnvoll, sich intensiv Gedanken darüber zu machen, wie man die Einrückungsebenen im Vornherein minimieren kann.

hustbaer

Wenn man guten Code schreibt, kann man dann nur noch 68 Zeichen benutzen

Was hat es mit gutem oder schlechtem Code zu tun ob ich bei Spalte 78 oder 80 oder 120 Schluss mache???

7H3 N4C3R

Lesbarkeit auf individuellen Text-Editoren und Druckbarkeit z.B., das ist schon korrekt - zumal in der Tat unsere Coderichtlinien hier 80 Zeichen sagen.
Allerdings muss man einen Namespace für die ganze Datei meiner Meinung nach auch nicht unbedingt einrücken.

Wie schaut's denn aus mit der sprachlichen Richtigkeit und konkreten Sprachproblemen?

Thomas ** 0

Das hat was mit Drucken zu tun
Ausserdem ist es inzwischen eben einfach Norm, viele Editoren zeigen ja auch die vertikale Linie an.

Konrad Rudolph

hustbaer schrieb:

Wenn man guten Code schreibt, kann man dann nur noch 68 Zeichen benutzen

Was hat es mit gutem oder schlechtem Code zu tun ob ich bei Spalte 78 oder 80 oder 120 Schluss mache???

Ich benutze eine Bildschirmbreite von 1280 Pixeln und arbeite im Vollbildmodus. Das heißt, ich kann in einem Editor mit Seitenleisten die 120 Zeichen fast sehen. Trotzdem verwende ich im Normalfall nur 80 (maximal 100) Zeichen auf einer Zeile, weil es viel sauberer zu lesen ist. Zu lange Zeichen werden vor dem Auge einfach zum Wirrwar und es ist anstrengend, das zu entwirren.

Hinzu kommt, dass die meisten Leute kleinere Bildschirme haben und nicht im Vollbildmodus arbeiten (tue ich auch nicht gerne). Ich habe z.B. schon an einem Projekt gearbeitet, in dem ich mir den Monitor mit sechs Editoren nebeneinander und übereinander angeordnet zugepflastert habe, weil ich alle Codes gleichzeitig einsehen musste. Wenn ich da mit mehr als 80 Zeichen gearbeitet hätte, wäre ich verrückt geworden (so habe ich das knapp überstanden).