3. Codingstyle?

Codingstyle?

  • ?

    Wahrscheinlich haben die den Styleguide auch nur irgendwo per Copy&Paste übernommen. 😃 Mozilla hat nämlich auch solche Schoten drin stehen.

    0
  • N

    Wieso haben eigentlich so viele das Gefühl, sie müssen den Codestil von irgendwelchen angeblich modernen und professionellen Internetseiten übernehmen?Meiner Ansicht nach gibt es schon gute Vorschläge für Stile, aber was spricht denn dagegen, nicht einen bereits bestehenden 1:1 zu übernehmen?

    Gerade das ist ja wohl das Paradebeispiel für einen miserablen C++-Codestil:

    1. Don't use C++ templates
    2. Don't use C++ exceptions
    3. Don't use RTTI
    4. Don't use namespaces
    5. Don't use STL
    ...

    Da frag ich mich echt auch, wieso die nicht mit C programmieren. Aber das sind wahrscheinlich solche Leute, die Makros wo nur möglich einsetzen, und ihre Container jedesmal selber basteln (viel Spass, vor allem bei der Performance), und und und...
    Überhaupt finde ich es unangebracht, wenn irgendwelche Leute denken, sie hätten den einzig wahren Codestil gefunden. Mit der ungarischen Notation kann ich beispielsweise überhaupt nichts anfangen, das scheint für mich eher ein verzweifelter Versuch, dreckigen Code durch die UN noch einigermassen ordentlich aussehen zu lassen...

    Aber natürlich, jedem das Seine; wenn man damit zurecht kommt, ist ja alles in Ordnung. Ich kann es nur nicht verstehen, wenn man sich verkrampft an irgendwelche Pseudo-Normen zu halten versucht, obwohl man selber auch ganz anderer Überzeugung ist...

    0
  • D

    asc schrieb:

    Shade Of Mine schrieb:

    was aber software betrifft die auf windows, mac, linux, bsd, solaris,... laufen soll - da sind diese guidelines 10-15 jahre zu alt.

    Oder um dein Kommentar mal zu mißbrauchen:

    Googles Coding Style - ewig nicht mehr aktualisiert 😞

    cu André

    Scheint so, aber ich finde das echt ein wenig traurig. Ein so grosses Unternehmen und ein Unternehmen, dass so jugendlich und dynamisch Auftritt, sollte da doch ein Beispiel sein und allen voran gehen.
    Ich gehe sogar so weit zu glauben, dass dieser Standard intern nicht eingehalten wird und die Mittel dennoch genutzt werden. Ich kann mir das einfach nicht vorstellen.

    0
  • ?

    Ich habe mir gerade libjingle angeguckt und dort habe ich z.B. STL, Namespace und Templates gefunden.

    0
  • *

    nurf schrieb:

    Das sind ja echt die Sahnestücke oben im Zitat :
    ➡ RTTI, Exceptions, Konstruktoren ...

    Das ist der letzte Müll. Das führt nur wieder zum alt bekannten ignorieren von Fehlermeldungen und des beliebten Fehlerhandlings "exit(EXIT_FAILURE);". So sinnvolle Dinge wie Destruktoren grundsätzlich als "throw ()" zu deklarieren wird kein Wort verloren.

    0
  • U

    Naja - aber

    Do only trivial initialization in a constructor. If at all possible, use an Init() method for non-trivial initialization.

    find ich gar nicht sooo verkehrt...
    Mach ich selbst zwar auch nicht, aber es wäre eigtl mal eine Überlegung wert - weil (vermutlich bis zum nächsten Standard kein Ctor einen anderen aufrufen kann) - und so kann man Klassen wenigstens "wiederverwenden"...

    Oder seh ich das komplett falsch?

    bb

    0
  • D

    unskilled schrieb:

    Naja - aber

    Do only trivial initialization in a constructor. If at all possible, use an Init() method for non-trivial initialization.

    find ich gar nicht sooo verkehrt...
    Mach ich selbst zwar auch nicht, aber es wäre eigtl mal eine Überlegung wert - weil (vermutlich bis zum nächsten Standard kein Ctor einen anderen aufrufen kann) - und so kann man Klassen wenigstens "wiederverwenden"...

    Oder seh ich das komplett falsch?

    bb

    Das ist ja nur eine Konsequenz aus der Regel das man keine Exceptions verwenden darf.

    0
  • N

    unskilled schrieb:

    weil (vermutlich bis zum nächsten Standard kein Ctor einen anderen aufrufen kann)

    Wieso sollte man das nicht können? Das passiert ja bei allen Elementen, deren Typ kein Grundtyp von C++ ist.
    In der Initialisierungsliste kann man die Konstruktoraufrufe auch explizit aufschreiben, ansonsten wird der Standardkonstruktor aufgerufen.

    Ich find Init() -Methoden nicht gerade schön, das hebelt das ganze Konzept von Konstruktoren aus. Für mich ist das eher ein Anzeichen von schlechtem Design. Wie ist das begründet, dass man nur triviale Dinge im Konstruktor regeln und den Rest in Funktionen auslagern sollte?

    0

  • Wie ist das begründet, dass man nur triviale Dinge im Konstruktor regeln und den Rest in Funktionen auslagern sollte?

    Der "üblichste" Grund den ich kenne ist dass keine Exceptions verwendet werden sollen (warum auch immer).

    Allerdings gibt es da ein Pattern mit dem sich eine 2-Phase Construction immer noch verhindern lässt, trotz "keine Exception". Man gibt dem ctor eine Referenz auf einen Errorwert mit:

    class foo {
public:
    foo(int& error) {
        if (error == 0) {
            // initialize foo
            if (!whatever()) {
                error = 123;
                return;
            }
        }
    }
};

    Dadurch entfällt 1) die Notwändigkeit einer Initialize() Funktion, und man kann Konstruktoren einfach "verketten":

    class bar {
public:
    bar(int& error)
        : m_foo1(error), m_foo2(error) {
        if (error == 0) {
            // error == 0 means m_foo1 and m_foo2 have been fully constructed
            // initialize bar
            if (!whatever()) {
                error = 123;
                return;
            }
        }
    }
private:
    foo m_foo1;
    foo m_foo2;
};

    Soll allerdings keine Empfehlung sein, ich finde es grundsätzlich grässlich wenn eine Klasse so implementiert ist dass man irgendwie zu "untoten" Objekten kommen kann, also welchen die es zwar gibt, aber die halt noch nicht/nicht mehr wirklich "da" sind. In Sprachen ohne deterministische Finalisierung muss man einfach damit leben. Bloss wieso sollte man sich das in C++ antun?

    0
  • F

    Noch ne Variante:

    foo::foo( int& error ) {
    if (error == 0) {
        // initialize foo
        if (!whatever()) {
            error = 123;
            return; }}}

bar::bar( int& error )
    : foo1_(error)
    , foo2_(error) {
    if (error == 0) {
        // error == 0 means m_foo1 and m_foo2 have been fully constructed
        // initialize bar
        if (!whatever()) {
            error = 123;
            return; }}}
    0
  • O

    was spricht jetzt eigentlich gegen exceptions?

    diese konstrukte mit error sind ziemlich fürn arsch. und man muss sich, wie hustbaer sagte, mit untoten objekten rumschlagen.

    0
  • ?

    Immerhin schreibt Google mit diesen Regeln gute Programme. Sind bei denen die Serverseitigen Programme auch in C++ geschrieben, oder nur sowas wie Google Earth?

    PS: Wer solche Konstruktoren schreibt die an 10 Stellen Exceptions werfen können, der hat doch sowieso schon was falsch gemacht. Alle großen C++ Libs die mir so einfallen kommen ohne unmengen an Exceptions in Konstruktoren und sonst wo aus.

    0
  • O

    hypermegaprocoder schrieb:

    Wer solche Konstruktoren schreibt die an 10 Stellen Exceptions werfen können, der hat doch sowieso schon was falsch gemacht. Alle großen C++ Libs die mir so einfallen kommen ohne unmengen an Exceptions in Konstruktoren und sonst wo aus.

    richtig. manchmal muss es aber sein. spätestens wenn du irgendwas hast, dass direkt auf lockbare hardware zugreifen muss, wie soundkarte, grafikkarte, usw, wirds kritisch. Man kann es umgehen, aber es ist sinnvoll zu wissen, wie man mit sowas umzugehen hat.

    0
  • D

    Nexus schrieb:

    unskilled schrieb:

    weil (vermutlich bis zum nächsten Standard kein Ctor einen anderen aufrufen kann)

    Wieso sollte man das nicht können? Das passiert ja bei allen Elementen, deren Typ kein Grundtyp von C++ ist.
    In der Initialisierungsliste kann man die Konstruktoraufrufe auch explizit aufschreiben, ansonsten wird der Standardkonstruktor aufgerufen.

    Ich find Init() -Methoden nicht gerade schön, das hebelt das ganze Konzept von Konstruktoren aus. Für mich ist das eher ein Anzeichen von schlechtem Design. Wie ist das begründet, dass man nur triviale Dinge im Konstruktor regeln und den Rest in Funktionen auslagern sollte?

    Ich frag mich grade wie lange man wohl debuggen muss, damit man den Bug enddeckt das irgend einer vergessen hat init() aufzurufen.

    class GoogleRegeln
{
    public:
      GoogleRegeln() : error(0) { }
      int init()
      {
          // initialliserire das Objekt
          return 0;
      }
}

// ...

GoogleRegeln* obj = new GoogleRegeln();
// obj->init() vergessen
// ...
obj.foo();
obj.bar();
    0
  • P

    DEvent schrieb:

    8. Don't use new logical operators keywords

    Das wusste ich gar nicht das C++ solche keywords hatt.

    Hat es. Es sind die üblichen: and, or, not. Dass die nicht so bekannt sind liegt AFAIK daran dass ein oder zwei größere Compiler (MSVC?) die Dinger nicht unterstützen. Was widerum in meinen Augen ein Armutszeugnis des Compilerherstellers ist. Wenn irgendwelche komplizierten template-Konstrukte nicht ganz so funktionieren wie der Standard es vorsieht, naja. Aber diese Keywords sollten nunmal echt billig zu implementieren sein.

    0
  • U

    Ich meinte den "eigenen" CTor...

    Wundertolles Beispiel folgt:

    struct ali_nix_schuld
{
bool ist_ali_schuld;
bool ali_wirklich_nicht_schuld;

ali_nix_schuld (bool ist_wahr_fragezeichen)
: ist_ali_schuld (ist_wahr_fragezeichen), ali_wirklich_nicht_schuld (ist_wahr_fragezeichen)
{}

ali_nix_schuld (const Tperson &schuldiger)
: ali_nix_schuld (false)
{
//noch was mit Tperson machen
}

ali_nix_schuld (const Tobject &missverstaendnis)
: ali_nix_schuld (false)
{
//noch was mit Tobject machen
}
};

    bb : )

    0

  • Wie wäre es denn, wenn mal jemand, der sich einen guten Programmierstil zutraut, ein paar Grundregeln veröffentlicht. Auch meinetwegen Codebeispiele. Damit meine ich nicht nur den eigenen Standpunkt zu Exceptions, oder Templates, sondern auch den Faktor "Lesbarkeit / optische Erscheinung" des Codes.

    Falls es sowas hier schon gibt, bitte ich um einen Link, da ich gern mal wissen würde, wie andere so coden und was ich vielleicht selbst besser machen könnte.

    0
  • K

    pumuckl schrieb:

    DEvent schrieb:

    8. Don't use new logical operators keywords

    Das wusste ich gar nicht das C++ solche keywords hatt.

    Hat es. Es sind die üblichen: and, or, not. Dass die nicht so bekannt sind liegt AFAIK daran dass ein oder zwei größere Compiler (MSVC?) die Dinger nicht unterstützen. Was widerum in meinen Augen ein Armutszeugnis des Compilerherstellers ist. Wenn irgendwelche komplizierten template-Konstrukte nicht ganz so funktionieren wie der Standard es vorsieht, naja. Aber diese Keywords sollten nunmal echt billig zu implementieren sein.

    Microsofts Antwort darauf ist „won't fix“. Ich habe das als Bugreport gemeldet und m.E. auch argumentativ untermauert. MS' Gegenargument war, dass sich bisher noch niemand beschwert hat.

    0
  • Administrator

    Konrad Rudolph schrieb:

    Microsofts Antwort darauf ist „won't fix“. Ich habe das als Bugreport gemeldet und m.E. auch argumentativ untermauert. MS' Gegenargument war, dass sich bisher noch niemand beschwert hat.

    Darf ich fragen, wie du das argumentativ untermauert hast? Ich finde irgendwie kein sinnvolles Argument dafür. Mir ist es bis Heute überhaupt ein Rätsel, wieso diese Keywords eingeführt worden sind. Wofür? Verwendet die überhaupt jemand, bzw. würde die überhaupt jemand verwenden?

    Grüssli

    0
  • S

    Dravere schrieb:

    Verwendet die überhaupt jemand, bzw. würde die überhaupt jemand verwenden?

    Damit man auf exotischen Tastaturen C Programmieren kann. Siehe http://en.wikipedia.org/wiki/Iso646.h

    Das ganze ist natuerlich heute laengst ueberholt.

    0
Anmelden zum Antworten