Hallo Besucher, der Thread wurde 13k mal aufgerufen und enthält 93 Antworten

letzter Beitrag von Zirias/Excess am

C Frage ist folgendes zulässig?

    Zitat von zrs1

    Kann natürlich jeder machen wie er will. Aber diverse Diskussionen (z.B. hier) legen nahe, dass eine Mehrheit Code ohne solche typedefs lesbarer findet (die akzeptierte Antwort dort geht auf genau den Fall ein, in dem viele so ein typedef sinnvoll finden: Genau dann, wenn man gar nicht wissen SOLL, dass es sich um einen Pointer handelt).

    Also typedefs generell find eich ganz nützlich in bestimmten Situationen. Um einen Pointer "zu verstecken" finde ich das aber furchtbar, weil ich dann im Code immer im Zweifel bin ob ich gerade einen Pointer oder ein Objekt benutze.


    Wo ich es ganz nützlich finde ist bei Funktionstypen. z.B.


    Code
    1. int (*MyFunktion)(int a, char *p);


    Wenn man dann einen Funktionspointer hinschreibt wird das schnell kompliziert deswegen ist es da recht nützlich wenn ich das mit einem typedef lesbarer mache.

    Code
    1. typedef int (*MyFunktionPtr)(int a, char *p);

    @sparhawk Bei Funktionstypen ist denke ich ein typedef allgemein anerkannt als "besser lesbar". Allerdings sind mir da auch schon zwei unterschiedliche Stile untergekommen: typedef mit oder ohne den Pointer. In dem speziellen Fall gefällt mir die Variante mit Pointer IM typedef (wie auch in deinem Beispiel) besser, da ich keine sinnvolle Anwendung für einen Funktionstyp ohne Pointer kenne :)

    Zitat von zrs1

    Kann natürlich jeder machen wie er will. Aber diverse Diskussionen (z.B. hier) legen nahe, dass eine Mehrheit Code ohne solche typedefs lesbarer findet (die akzeptierte Antwort dort geht auf genau den Fall ein, in dem viele so ein typedef sinnvoll finden: Genau dann, wenn man gar nicht wissen SOLL, dass es sich um einen Pointer handelt).

    Ja, diskutieren kann man viel und viele Leute haben oft vorgefertigte Meinungen. Hatte ich auch, bis ich dann selbst mit diesem Code konfrontiert wurde, und dadurch erfahren haben wie praktisch das ist und die Syntax vorallem von Template code dadurch überschaubarer wird.

    Zitat von mrsid

    Ja, diskutieren kann man viel und viele Leute haben oft vorgefertigte Meinungen.

    Also ich möchte dazu nur sagen, an meiner Meinung zu diesem Thema ist wirklich nichts "vorgefertigt", die hat sich entwickelt. Ich habe in meinen Anfangszeiten in C durchaus auch mal typedefs für Pointer geschrieben. Nach meiner Erfahrung hat sich das nicht bewährt. Ich habe absolut nichts gegen typedefs, die die Lesbarkeit erhöhen -- und speziell bei komplexen Template-Konstrukten in C++ kann das sicher recht sinnvoll sein. Ich bin nur absolut dagegen, Dinge wie Pointer und const im typedef zu "verstecken". Da muss ja nicht jeder meiner Meinung sein, aber ich finde das eben weder intuitiv noch besonders lesbar :)

    Wir verwenden einfach den Allman Style, aber mit Sakrileg: Einzeilige Blöcke brauchen keine { }, also:


    Code
    1. if (x == 0)
    2. BlaBla();

    statt

    Code
    1. if (x == 0)
    2. {
    3. BlaBla();
    4. }

    Das ist auch so ein rotes Tuch für bestimmte Leute. In der Praxis habe ich aber die Erfahrung gemacht das erstere Variante praktisch nie wirklich zu Problemen führt. Vielleicht 3x in 10 Jahren oder so.

    In meiner jetzigen Firma haben wir die Regel dass wir auch bei Einzeilern die Klammenr setzen müssen. Das nervt mich total weil ich der Meinung bin dass es den Code unnötoig aufbläht, aber kann man schlecht was machen. :)
    Das Ärgerlichste daran ist dass wir uns diese Regeln selbst zusammenstellen können, innerhalb der Teams. Und alle in meinem Team wollen das so (oder zumindest die Mehrheit)...

    Hehe ... @mrsid -- es ist sicher unwahrscheinlich, durch so etwas Bugs einzubauen. Aber wenn es doch mal passiert, dann nach Murphy natürlich da, wo es RICHTIG weh tut. ;)


    Das "rote Tuch" kommt also auch nicht von ungefähr. Obwohl man natürlich auch sagen muss -- es gäbe genug andere Möglichkeiten, solche Bugs zu verhindern, außer hier konsequent zu klammern (wie wäre es z.B. mit Unit-Tests zumindest für kritische Komponenten?)


    Ich finde es gibt hier noch eine nette Alternative:

    Code
    1. if (x == 0) BlaBla();

    Wenn so ein simples Konstrukt in eine Zeile passt, warum nicht einfach so schreiben? Wenn dann später jemand da mehr Funktionalität einbauen will muss er erstmal die Zeile brechen -- dann zu vergessen, auch einen Block hinzuschreiben, dürfte wirklich unmöglich sein...

    Zitat von zrs1
    Code
    1. if (x == 0) BlaBla();

    Wenn so ein simples Konstrukt in eine Zeile passt, warum nicht einfach so schreiben? Wenn dann später jemand da mehr Funktionalität einbauen will muss er erstmal die Zeile brechen -- dann zu vergessen, auch einen Block hinzuschreiben, dürfte wirklich unmöglich sein...


    Wie setze ich einen Breakpoint auf "BlaBla()" und wie einen auf die IF-Abfrage?

    Zitat von zrs1

    Ich finde es gibt hier noch eine nette Alternative:

    Code
    1. if (x == 0) BlaBla();

    Wenn so ein simples Konstrukt in eine Zeile passt, warum nicht einfach so schreiben? Wenn dann später jemand da mehr Funktionalität einbauen will muss er erstmal die Zeile brechen -- dann zu vergessen, auch einen Block hinzuschreiben, dürfte wirklich unmöglich sein...


    Also das finde ich richtig Schlimm. Warum ich das Schlimm finde ist schlicht und einfach das Debuggen, weil der Breakpoint dann nicht eindeutig ist. Will man dann einen BP nur wenn das if erfüllt ist, dann muss man erstmal umformatieren.


    Hab schon mit solchen Code arbeiten müssen und nur Probleme damit gehabt.

    Zitat von zrs1

    Das ist nun wirklich eine Frage vom Tooling -- ein gescheiter Debugger kann conditional breakpoints :)

    Tja... manchmal kann man sich das Tooling nicht aussuchen! (Ich arbeite hauptsächlich für Fremdfirmen; da wird mir in aller Regel
    vorgeschrieben was ich zu benutzen habe).


    Und dann gibt's da noch diverse Toolchains für Embedded Systeme... die können das auch nicht immer.


    Zitat von sparhawk

    Also das finde ich richtig Schlimm. Warum ich das Schlimm finde ist schlicht und einfach das Debuggen, weil der Breakpoint dann nicht eindeutig ist. Will man dann einen BP nur wenn das if erfüllt ist, dann muss man erstmal umformatieren.


    Hab schon mit solchen Code arbeiten müssen und nur Probleme damit gehabt.

    So sieht es aus! <X

    Es gibt immer und überall Ausnahmen, aber in der Regel finde ich es falsch, Entscheidungen an Tools auszurichten. Der Einzeiler ist (wenn er wirklich so kurz ist) gut lesbar und kompakt, und verhindert solche Fails wie den (zugegebenermaßen unfassbar dämlichen) Apple-Bug. Wenn man gute Gründe hat, das nicht zu machen, dann macht man es auch nicht (und muss dann eben noch entscheiden: klammern oder nicht). Ansonsten ist es durchaus eine Alternative :)


    Manche Dinge kann man sich auch sparen, zum Beispiel fullquotes mit "kotz-smiley"... mein Vorschlag mag nicht für jeden passen (ist ja auch normal), "zum kotzen" ist er aber ganz sicher nicht.