C:Style

[Xin]

Das Thema interessiert mich sehr.

Ja, es ist auch nicht wirklich leicht etwas gutes zu finden. Aber man entwickelt sich weiter. Wenn ich mir heute einen Code von mir von vor ein paar Jahren anschaue, dann denke ich mir, wie habe ich das nur so formatieren können

*grins*

Code: Alles auswählen

int main( int argc, char ** argv )
{
  if( argc > 1 )
  {
    printf( "> 1\n" );
    }
  else
  {
    printf( "<= 1\n" );
    }
  }

Der wurde mir seinerzeit, so Mitte/Ende der 90er von meinem Editor aufgedrückt, der zwar wunderbar nach den Klammern reagieren konnte und automatisch die Einrückung korrigierte, aber eben 'nach' der Klammer... darum blieb die schließende Klammer da, wo sie war. Störte mich nicht.
Ich kann mit diesem Einrückungsstil weiterhin problemlos leben und ihn gut lesen. Geändert habe ich nur aus einem einzigen Grund: Der Rest der Welt konnte es nicht. Also konnte ich es auch nicht verantworten, jemandem C mit diesem Einrückungsstil beizubringen. Ich habe also überall 'normal' programmiert, außer für mich und da ich immer mehr Leuten programmieren beibrachte und immer mehr gegen Geld programmierte...
Inzwischen habe ich vermutlich alle wichtigen, aktuellen Quelltexte umgestellt.

Lokale Variablen/globale Funktionen werden klein geschrieben. (int i; initProgramm())

Und was ist wenn die Variablen aus mehr als nur einem Wort bestehen?

wie initProgramm?

Typnamen und Typmember werden groß geschrieben. (Typname->TypMember)

Da unterscheide ich lieber nach Funktion und Variable. Memberfunktionen schreibe ich so wie du globale Funktionen schreibst, weil das sie Member sind erkennt man ja sowieso an der Klasse davor (Typname->memberFunction).

Könnte ich mir als Ich->koche( spaghetti ) erklären. Kann ich gut mit leben, auch wenn ich es zur Zeit die alten AmigaOS Zeiten nicht überwunden habe und daher immernoch Ich->Koche( spahetti ); schreibe. Member schreibe ich groß: Ich->Koche( Spaghetti );
Würde man danach gehen, müssten Variablen Groß geschrieben werden, sofern es keine Funktionspointer sind. ^^

Und Variablen schreibe ich eigentlich immer klein mit Unterstrichen getrennt. In Klassen/Strukturen etc. stelle ich dann noch einen Unterstrich davor, damit es erstens keine Kollisionen mit Parametern und lokalen Variablen geben kann und zweitens auch mit Autovervollständigung mit Eingeben von nur dem Unterstrich gleich alle Membervariablen kommen.

Ich verabscheue Unterstriche... Konventionen wie bei GTK sind mir ein Graus!

In Genesys verlange ich jetzt nach VB-Vorbild den Punkt zur Unterscheidung.

Code: Alles auswählen

  .Counter = 1;

da es mir erlaubt einer Klasse ohne Interpretationsspielraum Member zu geben, deren Namen identisch mit dem Datentypnamen sind.
Damit ergibt sich, dass Memberdaten genauso geschrieben werden müssen, wie die Klassen, also üblicherweise groß. Auf kleingeschriebene Funktionen kann ich mich problemlos einlassen:

Code: Alles auswählen

.koche( .Spaghetti ); // Funktion im Namensraum 'Ich', die Klasse hat einen Datenmember class Spaghetti & Spaghetti;

Konstanten sind bei mir Member eines Konstanten-Typs. Das Token von if z.B. heißt bei mir "Key::If" und ist eine Konstante vom Typ Key.

Würdest du das dann also etwa wie folgt machen?

Code: Alles auswählen

class Key
{
  public:
   static const Key If;
}

Also ich schreibe Konstanten generell groß, egal ob es sich um 'const'-Konstanten, Enums oder sonst irgendwas handelt.

Widerspricht meinem Lesefluss. Die Tatsache, dass Key::If konstant ist, bekomme ich spätestens vom Compiler gemeldet, wenn ich
Key::If = Key::Else;
versuche.
Die Semantik steckt in der Definition des Typs und muss - meines Erachtens - nicht mehr in der Schreibweise verdeutlicht werden.
Bei einem Vergleich - und dafür brauche ich die Konstanten schließlich - interessiert mich nicht, ob ein Operand konstant ist oder nicht.

Ich habe durchaus Lösungen für das Problem, indem ich deutlich mehr über Vererbung löse.

Damit wäre ich irgendwie nicht so zufrieden. Was wenn der Fall dann doch einmal eintritt

Welcher Fall?

Manchmal kommt es aber auch vor das ich einen etwas anderen Codingstandard verwende, zum Beispiel wenn ich STL ähnlich Container, Streams oder ähnliche Sachen schreibe. Dann gehe ich meistens in Header von Boost oder der Standardbibliothek und versuche es ähnlich hin zu bekommen...

Ein paar meiner Sachen sind im Stil meines alten Arbeitgebers gehalten, damit ich mir das angewöhne.
Das sehe ich heute allerdings nicht mehr so ganz ein... ^^

[Kerli]

Code: Alles auswählen

int main( int argc, char ** argv )
{
  if( argc > 1 )
  {
    printf( "> 1\n" );
    }
  else
  {
    printf( "<= 1\n" );
    }
  }

Der wurde mir seinerzeit, so Mitte/Ende der 90er von meinem Editor aufgedrückt, der zwar wunderbar nach den Klammern reagieren konnte und automatisch die Einrückung korrigierte, aber eben 'nach' der Klammer...

Also so einen Einrückung empfinde ich nicht wirklich gut lesbar

Lokale Variablen/globale Funktionen werden klein geschrieben. (int i; initProgramm())

Und was ist wenn die Variablen aus mehr als nur einem Wort bestehen?

wie initProgramm?

Ok, dh. bei dir schauen Funktionen und Variablen wirklich gleich aus. Früher habe ich das auch gehabt. Sogar mit Prefix (iVarName). Aber irgendwie finde ich es doch lesbarer wenn man auf den ersten Blick eine Variable von einer Funktion unterscheiden kann, und das auch wenn ich gerade keine IDE geöffnet habe.

Ich verabscheue Unterstriche... Konventionen wie bei GTK sind mir ein Graus!

Da merkt man stark die Einschränkungen von C. In C++ könnte man zum Beispiel anstatt andauernd gtk_* zu schreiben das ganze in Namespaces packen.

In Genesys verlange ich jetzt nach VB-Vorbild den Punkt zur Unterscheidung.

Code: Alles auswählen

  .Counter = 1;

So etwas habe ich ja auch noch nirgendwo gesehen. Dh. also der Punkt gibt sozusagen eine Referenz auf die aktuelle Klasse zurück?

Also ich schreibe Konstanten generell groß, egal ob es sich um 'const'-Konstanten, Enums oder sonst irgendwas handelt.

Widerspricht meinem Lesefluss. Die Tatsache, dass Key::If konstant ist, bekomme ich spätestens vom Compiler gemeldet, wenn ich
Key::If = Key::Else;
versuche.
Die Semantik steckt in der Definition des Typs und muss - meines Erachtens - nicht mehr in der Schreibweise verdeutlicht werden.
Bei einem Vergleich - und dafür brauche ich die Konstanten schließlich - interessiert mich nicht, ob ein Operand konstant ist oder nicht.

Stimmt eigentlich, so hab ich das noch gar nicht gesehen. Bei mir ist das irgendwie noch ein Überbleibsel der Preprozessor Defines und dem Codingstandard an der Uni.

Ich habe durchaus Lösungen für das Problem, indem ich deutlich mehr über Vererbung löse.

Damit wäre ich irgendwie nicht so zufrieden. Was wenn der Fall dann doch einmal eintritt

Welcher Fall?

Naja, wenn du einmal keine Vererbung verwenden möchstest bzw. kannst.

Ein paar meiner Sachen sind im Stil meines alten Arbeitgebers gehalten, damit ich mir das angewöhne.
Das sehe ich heute allerdings nicht mehr so ganz ein... ^^

Tja, bei Freeform Sprachen wird es immer viele Standards geben und vor allem Meinungen bezüglich des richtigen Standards geben.

[Xin]

Der wurde mir seinerzeit, so Mitte/Ende der 90er von meinem Editor aufgedrückt, der zwar wunderbar nach den Klammern reagieren konnte und automatisch die Einrückung korrigierte, aber eben 'nach' der Klammer...

Also so einen Einrückung empfinde ich nicht wirklich gut lesbar

Das sagen alle, weil sie es nicht gewohnt sind. Es ist genauso gut lesbar wie Klammern untereinander zu schreiben. Es macht aber außer mir vermutlich keiner. Und da es einfacher ist, Klammern untereinander zu schreiben, als die Welt zu etwas bekehren, was nicht besser als das Vorhandene ist, schreibe ich inzwischen die Klammern auch untereinander.

Ok, dh. bei dir schauen Funktionen und Variablen wirklich gleich aus. Früher habe ich das auch gehabt. Sogar mit Prefix (iVarName). Aber irgendwie finde ich es doch lesbarer wenn man auf den ersten Blick eine Variable von einer Funktion unterscheiden kann, und das auch wenn ich gerade keine IDE geöffnet habe.

Ich habe mich viel mit der Semantik von Programmiersprachen beschäftigt. Auf den ersten Blick gibt es zwischen Funktionen und Variablen gigantische Unterschiede...

Code: Alles auswählen

int value;
int & ref = value;
int & funktion(void) { return *value; }
int funktionValue(void) { return 7; }

Wenn man genau hinguckt sind sie jedoch das selbe...
Auf eine Funktion kann man nicht schreiben - wohl aber auf das Ergebnis einer Funktion. funktion() = 7; Das entspricht ref = 7. Grundsätzlich spricht auch nichts dagegen funktionValue() = 7; zu schreiben - es ist nur sinnlos, da der Stack nach dem Aufruf überschrieben würde. Also verbietet die Sprache es. Tut sie das?
Wenn ich ein Objekt in einer Funktion zurückgebe, dass bei Zuweisung eines Integers eine MessageBox liefert, was macht dann
getObject() = 7;
?
Semantisch ist es korrekt.

Was passiert beim Lesen? Eine Funktion berechnet einen Wert und kopiert ihn in die gewünschte Variable.
value = funktion();
Was passiert bei einer Variablen? Zum Beispiel ClassA->Member.IntValue?
Ganz einfach: Man berechnet einen Wert nämlich *(*(ClassA+ClassA::Member))+MemberType::IntValue) und kopiert ihn in die gewünschte Variable.

Schreiben ist lesen. ClassA->Member.IntValue = 7 macht nichts anderes als die Funktion: Sie rechnet die Adresse aus, wo die 7 hingeschrieben werden soll und gibt int & zurück, auf dieses int & wird die 7 geschrieben.

Der einzige Unterschied zwischen einer Funktion und einer Variable ist, dass der User bei einer Funktion sich einmischen darf, Bedingungen oder Schleifen Formulieren darf, während das bei einer Variablen nicht notwendig ist. Der Name der Variable ist aber nichts anderes als eine Funktion, um die Adresse des Speicherplatzes herauszufinden, wo die gewünschten Daten liegen oder geschrieben werden sollen - das gleiche wie eine Funktion.

Properties machen die Sache offensichtlicher: Hier lässt sich der Unterschied zwischen einer Variable und einer Funktion optisch genausowenig unterscheiden.

Ich verabscheue Unterstriche... Konventionen wie bei GTK sind mir ein Graus!

Da merkt man stark die Einschränkungen von C. In C++ könnte man zum Beispiel anstatt andauernd gtk_* zu schreiben das ganze in Namespaces packen.

Naja, das macht die Sache erst wieder sinnvoller, wenn man anschließend wieder alles mit using namesapce zusamemnwirft

In Genesys verlange ich jetzt nach VB-Vorbild den Punkt zur Unterscheidung.

Code: Alles auswählen

  .Counter = 1;

So etwas habe ich ja auch noch nirgendwo gesehen. Dh. also der Punkt gibt sozusagen eine Referenz auf die aktuelle Klasse zurück?

In gewisser Weise. Es ist qausi die kurzform für this->Counter. Und es ist für mich erforderlich. Und es unterscheidet den dynamischen Member Counter von einem statischen Member Counter.

Also ich schreibe Konstanten generell groß, egal ob es sich um 'const'-Konstanten, Enums oder sonst irgendwas handelt.

Widerspricht meinem Lesefluss. Die Tatsache, dass Key::If konstant ist, bekomme ich spätestens vom Compiler gemeldet, wenn ich
Key::If = Key::Else;
versuche.
Die Semantik steckt in der Definition des Typs und muss - meines Erachtens - nicht mehr in der Schreibweise verdeutlicht werden.
Bei einem Vergleich - und dafür brauche ich die Konstanten schließlich - interessiert mich nicht, ob ein Operand konstant ist oder nicht.

Stimmt eigentlich, so hab ich das noch gar nicht gesehen. Bei mir ist das irgendwie noch ein Überbleibsel der Preprozessor Defines und dem Codingstandard an der Uni.

Ich stelle inzwischen extrem viel in Frage, was aktuelle Programmiermethoden angeht. Mit der Entwicklungsgeschichte von Genesys ergab sich das einfach. Darum dauert die Entwicklung auch ewig, weil sich das Ziel lange immer weiter weg bewegt hat.

Naja, wenn du einmal keine Vererbung verwenden möchstest bzw. kannst.

Wann sollte ich keine Vererbung verwenden möchten oder können?

Tja, bei Freeform Sprachen wird es immer viele Standards geben und vor allem Meinungen bezüglich des richtigen Standards geben.

Mag sein. Der Standard ist eigentlich auch nicht sonderlich spannend - viel eher die Begründung dahinter.

[Xin]

Ich habe das ganze mal etwas auseinander gepflückt und nach start:style: verschoben.

Zwei Kapitel fehlen hier noch: Bei "Richtiges Aufteilen auf Funktionen" kann ich durchaus vorstellen, was gemeint ist; bei "Zusammenfassen von Daten und Variablen" würde mich interessieren, was gemeint war!?

[Kerli]

"Zusammenfassen von Daten und Variablen" würde mich interessieren, was gemeint war!?

Gute Frage Vermutlich irgendwie das man Variablen möglichst dort deklarieren soll wo man sie auch braucht und zb. nicht alle Variablen am Anfang auflisten.

[Xin]

Joah, das könnte man so umformulieren, wobei das eher Zusammenfassen von Algorithmen und Variablen wäre... das wäre sicherlich auch ein sinnvoller Punkt hier und ist vermutlich auch gemeint.
Wenn sonst noch jemandem was sinnvolles zu "Zusammenfassen von Daten und Variablen" einfällt oder sonstige Punkte, die er als Stilfrage behandelt wissen möchte... nur zu.