ANSI C Stil ok so? Ginge ich als C Dev durch?

supertux

DerGrosseC schrieb:

Z
Zu den Kommentar der Funktion und aussagekräftigen Variablen:

- Ich finde es aber sehr nützlich, so einen Kommentar zu haben,
  weil Variablenamen, egal wie gut benannt, sagen nix über den
  Context der Verwendung aus oder Begrenzungen oder Ausnahmebehandlung usw.
  Also falsch fand ich das jetzt nicht... wenn bloss jeder so gut dokumentieren würde.

Kommentare zu den Knackpunkten bzw. verwendete Algorithemen sind wichtig, ein Kommentar für jede Zeile hinderlich und auf Dauer nicht zu halten.

Außerdem ist es wichtig zu trennen, was man dokumentiert, sprich, was die Funktion macht und wie die Funktion etwas macht.

Wenn du mein Tipp mit doxygen wahrnimmst, dann musst du nur dokumentieren, was die Funktion macht. Dem Benutzer der Funktion interessiert in erster Linie nicht im Detail, wie genau die Funktion arbeitet. Wenn zum Verständnis ein bisschen über die Arbeitsweise der Funktion geschrieben wird, ist ok, aber nicht den gesamten Quellcode erklären (das ist eher kontraproduktiv; veränderst du den Algorithmus, musst du die Kommentare neu schreiben, also unnötige unproduktive Arbeit).

Ich bin nicht der einzige der das folgende dir sagt: verwende lieber aussagerkräftigere Variablennamen. Das hilft mehr als Kommentare.

DerKuchen schrieb:

Außerdem solltest du statt
x = x + 1
lieber
++x;
benutzen. Das ist für C Programmierer wesentlich einfacher zu lesen.

ist zwar egal, wenns so allein da steht, aber ich empfinde x++ noch ein kleines bisschen leserlicher.

DerKuchen

Stimmt auch wieder...
Das Preincrement-++ hab ich mir durch C++ angewöhnt, da es hier durchaus einen Unterschied macht.

Badestrand

DerKuchen schrieb:

Stimmt auch wieder...
Das Preincrement-++ hab ich mir durch C++ angewöhnt, da es hier durchaus einen Unterschied macht.

Ne, wenn eine native Zahl-Variable alleinstehend post-inkrementiert wird, wirst du höchstwahrscheinlich nicht mal nen Unterschied im Binary feststellen

PS: Das "nativ" soll "int", "short" oder Konsorten bedeuten

LordJaxom

_matze schrieb:

Der Präfix "p" steht in C/C++ eigentlich für einen Pointer. Kennzeichnet man damit in Java wirklich jedes Funktionsargument?

Ich bezweifle dass man das tut. Ich jedenfalls mache es nicht. Ich habe zwar schon Styleguides gesehen, die ein Prefix (allerdings häufiger "a" oder "an" als "p") vorsehen, aber glücklicherweise muss ich mich nicht an solch einen halten.

LordJaxom schrieb:

_matze schrieb:

Der Präfix "p" steht in C/C++ eigentlich für einen Pointer. Kennzeichnet man damit in Java wirklich jedes Funktionsargument?

Ich bezweifle dass man das tut. Ich jedenfalls mache es nicht. Ich habe zwar schon Styleguides gesehen, die ein Prefix (allerdings häufiger "a" oder "an" als "p") vorsehen, aber glücklicherweise muss ich mich nicht an solch einen halten.

ich halte in java gar nix von prefixes. in java kann man keine überraschungen erleben, wenn man mit einer variable hantiert. da es keine pointerarithmetik gibt, kann im grunde auch gar nichts schiefgehen.

manche empfehlen allerdings prefixes für member, um zuweisungsfehler auszuschließen. aber ich verlass mich da lieber auf compilerwarnings

_matze

Ich halte sprechende Variablennamen für sehr sinnvoll. Das schließt für mich auch entsprechende Präfixe ein. Member mit "m_" und Globale mit "g_" zu kennzeichnen, ist bei uns Pflicht und entspricht auch meiner persönlichen Meinung. "l_" für Lokale halte ich dagegen für übertrieben und unnötig, da eine nicht so gekennzeichnete Variable nach dem Ausschlussprinzip nichts anderes als eine lokale Variable sein kann. Funktionsparameter auch noch irgendwie zu kennzeichnen ist, wie gesagt, bei Funktionen, die man komplett im Blickfeld hat, ebenfalls unnötig. Aus demselben Grund sind Typen-Präfixe ("i" für int) gut, aber nicht für jede kleine Zählvariable nötig.

DerKuchen schrieb:

Das Preincrement-++ hab ich mir durch C++ angewöhnt, da es hier durchaus einen Unterschied macht.

ach, da war ja was mit temporären objekten und dem ganzen overhead, der dazu gehört. naja, C++ eben: einfach nur kaputt.

DerKuchen

Badestrand schrieb:

DerKuchen schrieb:

Stimmt auch wieder...
Das Preincrement-++ hab ich mir durch C++ angewöhnt, da es hier durchaus einen Unterschied macht.

Ne, wenn eine native Zahl-Variable alleinstehend post-inkrementiert wird, wirst du höchstwahrscheinlich nicht mal nen Unterschied im Binary feststellen

PS: Das "nativ" soll "int", "short" oder Konsorten bedeuten

Schon klar, aber bei Klassen macht es einen Unterschied (das ist das was ich eigentlich schreiben wollte).
Bei einem überladenen Postincrement muss ein temporäres Objekt erstellt werden, da man ja den Zustand vor dem Increment noch erhalten muss.
Das es bei nativen Datentypen absolut keinen Unterschied macht ist mir schon klar...

moin moin,
ich hab mir nicht alles durchgelesen, um genau zu sein eigentlich nur die überschrift und ein paar zeilen code, aber ...

mittlerweile gibt es doch ziemlich viele coding style und irgendwelche etiquetten die für ein projekt stehen
ein richtig und ein falsch gibt es hier garnicht, man muss für sich entscheiden was einem am besten gefällt oder sich evtl. allgemein annerkannten regeln unterordnen wie z.b. beim kernel

ich persönlich habe mir auch meinen eigenen stil aus verschiedenen zusammengebaut, größtes manko dabei ist, dass ich keine kommentare bzw nur sehr wenige verwende
aber ansonsten könnten auch außenstehende ohne probleme den code schnell verstehen