3. Style-off

Style-off

  • E

    { sollte imo auf gleicher Höhe wie } sein. So erkennt man sofort den Block und muss nicht erst umständlich nach dem passenden { zum } suchen oder umgekehrt.

    Es sieht einfach deutlich symmetrischer aus und das ist hier auch einfach deutlich schöner.

    In Java macht man das wahrscheinlich nicht, weil man da ja Verschachtelungen von Klassen in ctors mit news anbietet, dass man für einen Aufruf sonst 30 Zeilen bräuchte.

    Fast noch schöner als die ekligen:

    void bla(){
blub;}

// oder
void bla(){
blub;
}

    -Konstrukte finde ich:

    void bla(){
blub;     }

    🤡
    Da sieht man wenigstens, dass die zusammen gehören. Ne Zeile zu sparen ist da total unterkompensierend.

    Just4fun:

    void bla(){
    while(true){
        blub();}
          }

    usw. ^^

    0
  • V

    wxSkip schrieb:

    @volkard: Ich weiß nicht, was du meinst, aber erzähl mal, ich sag dir dann meine Meinung dazu 😃 .

    Der große Block in der Mitte erschlägt einen fast. Und macht mich sofort neugierig, weshalb es nicht ein asm bsr oder __builtin_clz ist.

    0
  • ?

    Mein Code auf der Arbeit ist eine einzige Katastrophe.
    Ich muss immer schnell schnell ans Ziel kommen und genauso sieht es hinterher aus.
    Keine Sau interessiert sich dafür wie ich programmiere. Keine Code-Reviews, keine Absegnung des Datenbankschemas, nix. Nur das Klickibunti-Ergebnis zählt.
    Wenn ich zwischendurch mal versuche mehr Wert auf guten Stil zu legen, komme ich nur zäh vorwärts. Wenn ich dagegen hacke wie ein Schwein geht alles fix, läuft stabil und jeder ist zufrieden. Vorerst zumindest. Änderungen sind entsprechend schwieriger aber andererseits habe ich genug Zeit bei der hingerotzten Erstimplementierung gespart.

    Nein, ich bin damit nicht glücklich.

    Privat bin ich zehnmal langsamer und gebe sehr mir viel Mühe was reine Ästhetik als auch "Architektur", Objektdesign, Entwurfsmuster, Wiederverwendbarkeit und Anwendung guter OO-Prinzipien betrifft.

    0
  • W

    @Eisflamme: Du übersiehst da ein Problem: Wenn du die Zeile mit der schließenden Klammer änderst, musst du hinten wieder Leerzeichen hinzufügen/löschen und falls sie länger wird als die vorherige, musst du auch noch Leerzeichen in der vorigen Zeile hinzufügen.

    Ich habe auch mal Code in dieser Art gesehen:

    void foo()
{
  int    nLen          ;
  char  *pStrPtr       ;
  char   pStr[530]     ;
}

    Gleiches gilt natürlich für solche Kommentare:

    /*************************************************
 * Kommentar v1.0                                *
 * Funktionsbeschreibung                         *
 *************************************************/
    0
  • W

    @volkard: Meinst du GetStringNumberType()? OK, aber ich habe auch schon Funktionen mit über 1000 Zeilen gesehen...

    EDIT: Oh, ich sehe gerade, ich sollte das ostr.close() und das istr.close() in den file-Funktionen entfernen, sonst kommt noch so einer und meint "FILESTREAMS KÖNNEN RAII!!!!!!" 😃

    EDIT2: Meinst du vielleicht, ich sollte bei der Funktion einen istringstream nehmen, ein double einlesen und mit dem Ergebnis und fail() das Richtige herausfinden? Das wäre zumindest ähnlich.

    0
  • V

    wxSkip schrieb:

    @volkard: Meinst du GetStringNumberType()?

    Nein, nur GetLeadingOnesCount().

    0
  • W

    volkard schrieb:

    wxSkip schrieb:

    @volkard: Meinst du GetStringNumberType()?

    Nein, nur GetLeadingOnesCount().

    Na ja, ich muss dir dazu sagen, dass BIN() ein Makro ist, das ein Template aufruft, welches die Zahl statisch konvertiert. Diese Funktion wird relativ oft bei UFT-8-Decoding aufgerufen, von daher wollte ich sie entsprechend optimieren.

    ///bin-to-hex static conversion

template<uint64_t param> struct hex_helper
{
    enum
    {
        val = (uint16_t(bool(param & 0x1000000000000000ull)) << 15)
        | (uint16_t(bool(param & 0x100000000000000ull)) << 14)
        | (uint16_t(bool(param & 0x10000000000000ull)) << 13)
        | (uint16_t(bool(param & 0x1000000000000ull)) << 12)
        | (uint16_t(bool(param & 0x100000000000ull)) << 11)
        | (uint16_t(bool(param & 0x10000000000ull)) << 10)
        | (uint16_t(bool(param & 0x1000000000ull)) << 9)
        | (uint16_t(bool(param & 0x100000000ull)) << 8)
        | (uint16_t(bool(param & 0x10000000ull)) << 7)
        | (uint16_t(bool(param & 0x1000000ull)) << 6)
        | (uint16_t(bool(param & 0x100000ull)) << 5)
        | (uint16_t(bool(param & 0x10000ull)) << 4)
        | (uint16_t(bool(param & 0x1000ull)) << 3)
        | (uint16_t(bool(param & 0x100ull)) << 2)
        | (uint16_t(bool(param & 0x10ull)) << 1)
        | (uint16_t(bool(param & 0x1ull)))
    };
};

#define BIN(value) (utils::hex_helper<(0x##value##ull)>::val)

    Sieht allerdings auch nicht besser aus... 🙄

    0
  • ?

    ich verstehe

    void bla(foo)
{
    last;
}

    trotzdem nicht ganz - daß die auf void bla(foo) folgende Zeile die Anfangszeile des Funktionsinhalts ist, ist doch nicht so überraschend, und wird außerdem durch die Einrückung (ich kenne niemanden, der nicht einrückt) sowieso schon optisch hervorgehoben. Warum noch eine zweite Hervorhebung durch Leerzeile.

    0
  • W

    !rr!rr_. schrieb:

    ich verstehe

    void bla(foo)
{
    last;
}

    trotzdem nicht ganz - daß die auf void bla(foo) folgende Zeile die Anfangszeile des Funktionsinhalts ist, ist doch nicht so überraschend, und wird außerdem durch die Einrückung (ich kenne niemanden, der nicht einrückt) sowieso schon optisch hervorgehoben. Warum noch eine zweite Hervorhebung durch Leerzeile.

    1. Gewohnheitssache.
    2. Ich finde es optisch schöner, weil ich es gewöhnt bin und weil die Klammern auf gleicher Höhe sind.
    3. Es ist einfacher mit der Code::Blocks Sonderzeichenergänzung zu kombinieren.

    0
  • V

    wxSkip schrieb:

    ...

    Hast Du gemessen, daß asm bsr oder __builtin_clz langsamer sind?

    0
  • W

    volkard schrieb:

    wxSkip schrieb:

    ...

    Hast Du gemessen, daß asm bsr oder __builtin_clz langsamer sind?

    Was ist das? Sieht nicht nach Standard-C++ aus.

    EDIT: __builtin_clz ist genau das Gegenteil von dem, was ich brauche (gibt führende Nullen zurück), asm bsr lässt sich leider nicht so gut finden. Auf GCC-Spezifische Sachen würde ich höchstens mit einem #ifdef zugreifen, inline-Assembler fände ich nicht so gut.

    0
  • V

    wxSkip schrieb:

    volkard schrieb:

    wxSkip schrieb:

    ...

    Hast Du gemessen, daß asm bsr oder __builtin_clz langsamer sind?

    Was ist das? Sieht nicht nach Standard-C++ aus.

    Und? Für außergewöhliche Architekturen kann man ja suboptimalen Standard-Code machen.

    size_t utils::binary::GetLeadingZerosCount(char_t in)
{
    return GetLeadingOnesCount(~in);
}
    0
  • W

    Ah, gut... (*hirn an*)
    char_t ist bloß leider meistens 32 Bits groß und der char ja bekanntlich 8 Bit... während unsigned int eher undefiniert groß ist :p ... Mal schauen.
    Und wenn ich den char von GetLeadingOnesCount in ein unsigned int konvertiere, dann __builtin_clz aufrufe und dann vom Ergebnis (sizeof(unsigned int)-sizeof(char)) * 8 abziehe, habe ich da so meine Zweifel, ob das schneller ist, zumal bei UTF-8 in den meisten Fällen gleich die erste if-Bedingung true liefern wird.

    0
  • V

    wxSkip schrieb:

    Ah, gut... (*hirn an*)
    char_t ist bloß leider meistens 32 Bits groß und der char ja bekanntlich 8 Bit... während unsigned int eher undefiniert groß ist :p ... Mal schauen.

    Ups, eine Asymmetrie der beiden Funktionen, die mir nicht aufgefallen ist (Gefahr).
    (Vielleicht auch hier schauen. http://graphics.stanford.edu/~seander/bithacks.html#IntegerLogDeBruijn )

    wxSkip schrieb:

    Und wenn ich den char von GetLeadingOnesCount in ein unsigned int konvertiere, dann __builtin_clz aufrufe und dann vom Ergebnis (sizeof(unsigned int)-sizeof(char)) * 8 abziehe, habe ich da so meine Zweifel, ob das schneller ist, zumal bei UTF-8 in den meisten Fällen gleich die erste if-Bedingung true liefern wird.

    Das wäre ein schöner Kommentar für die GetLeadingOnesCountByIfCascadeForUTF8AssumingAlmostAllInputReturningZero().

    Nicht, daß es wirkt, als wolle ich Deinen Code nur schlechtmachen.
    Erstmal 👍 für Deinen Stil. Den kann ich gut lesen.

    0
  • E

    @Eisflamme: Du übersiehst da ein Problem: Wenn du die Zeile mit der schließenden Klammer änderst, musst du hinten wieder Leerzeichen hinzufügen/löschen und falls sie länger wird als die vorherige, musst du auch noch Leerzeichen in der vorigen Zeile hinzufügen.

    Wie kommst Du darauf, dass ich das übersehe. Aber besser ein klein bisschen mehr Änderungsaufwand als die Lesbarkeit des Codes torpedieren. Ich finde es nach wie vor schrecklich, { keine eigene Zeile zu spendieren und ich erkenne die Blöcke einfach nicht. Ausnahme ist, wenn die } in der gleichen Zeile steht.

    0
  • W

    volkard schrieb:

    wxSkip schrieb:

    Ah, gut... (*hirn an*)
    char_t ist bloß leider meistens 32 Bits groß und der char ja bekanntlich 8 Bit... während unsigned int eher undefiniert groß ist :p ... Mal schauen.

    Ups, eine Asymmetrie der beiden Funktionen, die mir nicht aufgefallen ist (Gefahr).
    (Vielleicht auch hier schauen. http://graphics.stanford.edu/~seander/bithacks.html#IntegerLogDeBruijn )

    wxSkip schrieb:

    Und wenn ich den char von GetLeadingOnesCount in ein unsigned int konvertiere, dann __builtin_clz aufrufe und dann vom Ergebnis (sizeof(unsigned int)-sizeof(char)) * 8 abziehe, habe ich da so meine Zweifel, ob das schneller ist, zumal bei UTF-8 in den meisten Fällen gleich die erste if-Bedingung true liefern wird.

    Das wäre ein schöner Kommentar für die GetLeadingOnesCountByIfCascadeForUTF8AssumingAlmostAllInputReturningZero().

    Nicht, daß es wirkt, als wolle ich Deinen Code nur schlechtmachen.
    Erstmal 👍 für Deinen Stil. Den kann ich gut lesen.

    Die Seite ist ja lustig, was es alles gibt!
    Gut, über den Funktionsnamen könnte man sich streiten...

    Ich finde es auch interessant, mal in altem "unschönen" Code zu lesen, dafür umso weniger, ihn zu verbessern 😃

    0
Anmelden zum Antworten