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

Bashar

Hattest du gehofft, deine persönlichen Marotten würden rein zufällig mit dem "klassischen" Stil übereinstimmen? Ich bin irgendwie verwundert über die Motivation dieses Threads.

DerKuchen

Bezeichner mit zwei Unterstrichen am Anfang sind explizit für den Compiler reserviert. Auch wenn es normalerweise geht sollte man die nicht benutzen.

Die Parameter nochmal in lokale Variablen zu kopieren ist meiner Meinung nach völlig unnütz. Wenn sie nicht verändert werden sollen, nimm const, ansonsten ist es egal. Selbst dein Debugging Argument greift nicht, da du nur den Pointer kopierst, die dann aber beide auf den gleichen Speicherbereich zeigen. Wenn du das wirklich haben willst, musst du den String schon kopieren.
Abgesehen davon macht es den Code nicht gerade leserlicher, wenn die Parameter in der Funktion nicht mehr verwendet werden. Beim schnellen drüberlesen verwirrt das eher.

Deine Einrückungen find ich eher übertrieben. Da entstehen größere "Löcher" im Text, was den Lesefluss stört. Vor allem folgende Stelle fand ich sehr irritierend:

if ( ssp == 0 )
    i =      sp;
sp    =  sp + 1;
ssp   = ssp + 1;
match =    0xFF;

Durch das gleich ausgerichtete = wirkt das, als ob alle 4 Anweisungen zusammengehören. Das if geht da eher unter.

Meiner Meinung nach sollte die Signatur einer Funktion (also typ name(parameter)) in eine Zeile geschrieben werden, da lässt sich aber drüber streiten. Immerhin gehören diese Informationen direkt zusammen, deshalb sollte man sie nicht extra trennen.

Zu deinem bool wurde ja schon einiges gesagt, aber wenn es dir um "Ansi C Stil" geht, dann nimm 0 und 1. Alle Standard C Funktionen benutzen 0 und 1, daher sollte man sich da nicht unbedingt was eigenes ausdenken.

Variablen sollten eigentlich immer direkt bei der Deklaration initialisiert werden. Das ist allgemein "guter Stil", und dient unter Anderem dazu, dass keine uninitialisierten Variablen rumfliegen. Außerdem solltest du statt

x = x + 1

lieber

++x;

benutzen. Das ist für C Programmierer wesentlich einfacher zu lesen.

Den Kommentarblock finde ich völlig übertrieben, der ist länger als die eigentliche Funktion. Guter Code sollte selbstdokumentierend sein. Statt spp hättest du z.B. einfach substrPos nehmen können, und hättest einen Kommentar gespart.
Außerdem solltest du die Kommentare zu den betreffenden Code Zeilen schreiben, nichts ist nerviger als ständig scrollen zu müssen, um etwas nachzusehen. Das hilft auch dabei die Kommentare aktuell zu halten.

Eine Anmerkung hätte ich noch, auch wenn es weniger stilistischer Natur ist: Statt der Länge des Strings als Rückgabewert für einen Fehler würde ich lieber -1 nehmen, das lässt sich wesentlich leichter von einer guten Rückgabe unterscheiden. Außerdem ist der Test auf Fehler dann einfacher.

_matze

DerGrosseC schrieb:

- In der Java Vorlesung haben wir Parameter immer mit "p" als Prefix definiert:
public static int foobar (int pBreite) {
int Breite;
Breite = pBreite;
// Arbeite weiter mit Breite.
return Breite;
}

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

Wenn du damit jeden Parameter kennzeichnest, führt das jeden C/C++-Programmierer in die Irre. Das wird spätestens wichtig, wenn du beruflich programmierst und dich mit Kollegen arrangieren musst.

Wenn dir die Kennzeichnung von Parametern aber so wichtig ist, könntest du dir ja was ausdenken und z.B. "p_" o.ä. verwenden. Ein als Parameter der Funktion übergebener unsigned int Pointer könnte dann "p_puiVarName" heißen. Man kann es mit der Ungarischen Notation aber auch übertreiben. Das merkt man spätestens, wenn die Präfixe die eigentlichen Variablennamen in der Länge übertreffen.

Gerade im Hinblick darauf, dass Funktionen grundsätzlich nicht zu groß werden sollten, ist eine Kennzeichnung als Parameter imho für die Übersicht unnötig.

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