Wie findet ihr diesen Programmier Stil in C?

In der Schule müssen wir in diesem Stil programmieren:

#include <stdio.h>

int main(void)
{
      printf("Hello, World!");
      return 0;
} // end main

Wir findet ihr das?

Ich finde man sollte selbst entscheiden welchen Programmierstil man verwendet, solange der Code lesbar und verständlich ist.

Answer 1

[regex9]

Wir findet ihr das?

Gut, denn so habt ihr erst einmal eine Orientierung, die für mehr Ordnung sorgt. Euch und eurem Lehrer hilft es, den Code besser überschauen zu können.

Ich finde man sollte selbst entscheiden welchen Programmierstil man verwendet, (...)

Für eigene Hobbyprojekte mag das gelten. Für Arbeiten, mit denen sich auch andere noch beschäftigen müssen (also beispielsweise bei Teamprojekten) hingegen ist es hinderlich, wenn jeder meint, seinen eigenen Stil verfolgen zu müssen. Dann entsteht nämlich wieder das Chaos, welches man eigentlich durch eine Konvention vermeiden möchte. Für die Kollegen (oder konkret in deinem Fall dem Lehrer), die nur einmal kurz mit auf den eigenen Bildschirm schauen sollen, um bei einem Problem zu helfen, wird es schwieriger/aufwendiger, sich einzulesen.

Stell dir im Vergleich dazu einfach nur einmal vor, du müsstest für 50 Dokumente prüfen, wer der Autor ist. Manche schreiben den Namen auf die Vorderseite links oben, andere schreiben ihn unter den Titel oder ganz unten auf die Rückseite. In der Einzelbetrachtung mögen das alles übersichtliche, saubere Lösungen sein. Sie in der Menge abzuarbeiten, ist allerdings aufwendig.

Das ist übrigens ein Grund, wieso viele Entwicklerteams Code Reviews in ihren Arbeitsprozess integriert haben und in manchen Fällen sogar Tools wie CPPLint, StyleCop, Vera++, u.ä..

Wie findet ihr diesen Programmier Stil in C?

So wie es in vielen anderen Antworten schon erwähnt wurde, halte ich den end-Kommentar ebenfalls für überflüssig. Er bedeutet mehr Schreibarbeit und man muss ihn bei der Wartung mit im Auge behalten (nimm nur einmal an, der Funktionsname wird geändert). Wenn man nun argumentiert, dass der Kommentar das Ende des Blocks besser sichtbar machen würde, müsste man meines Erachtes hinterfragen, ob die Einrückungen nicht richtig gesetzt wurden und ob der Blockkörper zu lang ist (wenn ja, müsste er aufgeteilt / verlagert werden).

Was man allerdings einmal prüfen könnte (und an der Stelle wäre sicherlich eine Umfrage innerhalb deiner Klasse/Schule interessant), wäre, ob der Endkommentar für Anfänger nicht doch eine hilfreiche Stütze ist, die verhindert, dass man beim Schreiben die Endklammer eines Blocks vergisst (unabhängig der Tatsache, dass der Editor/Compiler ebenso eine Fehlermeldung dazu ausspuckt).

Noch ein anderer verständlicher Grund wäre, falls ihr zuvor eine andere Programmiersprache wie VB oder Pascal gelernt habt. Der Kommentar könnte an der Stelle als temporäres Brückenkontrukt dienen, um sich an die geschweifte Klammer zu gewöhnen.

Hinsichtlich der Einrückung halte ich vier Leerzeichen für gut geeignet. Wenn du ältere C-Codes findest (s. bspw. Linux Kernel-Implementation), könntest du durchaus häufiger auf acht Leerzeichen je Einrückung stoßen (begründet als Maßnahme, auch nach mehrstündiger Arbeit die Lesekonzentration noch aufrecht erhalten zu können). Dann allerdings mit der Konsequenz, bestimmte Verschachtelungstiefen konsequent früh umzuformen.

Die eigene Präferenz kann man heutzutage leicht über die Einstellung des genutzten Code-Editors lösen (Stichwort: Tabbreite).

Bezüglich der Klammersetzung richten sich meiner Erfahrung nach die meisten C-Codes an 1TBS oder K&R aus.

Beispiel für 1TBS:

int main(void) {
  int value = 1;

  if (value == 1) {
    printf("Is 1");
  }

  return 0;
}

Beispiel für K&R:

int main(void)
{
  int value = 1;

  if (value == 1) {
    printf("Is 1");
  }

  return 0;
}

Der Unterschied liegt hier also darin, dass bei K&R die geschweiften Klammern für die Funktionen, so wie bei Allman immer eine eigene Zeile bekommen. Bei Funktionen mit mehreren Parametern (die man aufgrund der Zeilenlänge tendentiell auf mehrere Zeilen umbrechen würde) hat das einen Vorteil, da so Kopf und Körper visuell stärker getrennt werden (bei Allman wird das natürlich ebenso für Verzweigungen und Schleifen gelöst).

Beispiel:

// 1TBS
void doSomething(
  int value1,
  int value2,
  int value3) {
  int sum = value1 + value2 + value3;
}

// K&R
void doSomething(
  int value1,
  int value2,
  int value3)
{
  int sum = value1 + value2 + value3;
}

Wobei es hierfür natürlich auch noch andere Lösungen gibt. Beispielsweise könnte man die Parameter in einem struct zusammenfassen, um die Parameterliste zu verkürzen.

Um letzten Endes zu einem Fazit zu kommen: Es ist meines Erachtens sinnvoll, sich mit unterschiedlichen Konventionen einmal auseinanderzusetzen (oft werden sogar je Programmiersprache Konventionen definiert und/oder es haben sich bestimmte Stile im Mainstream durchgesetzt), um die Ideen (Problemlösungen) dahinter kennenzulernen und eigene Schlüsse daraus ziehen zu können. Einiges lässt sich inzwischen ja schon anderweitig lösen - sei es über die Editoreinstellungen (wobei bedacht werden sollte, dass nicht jeder Entwickler zwingend mit denselben Tools arbeitet) oder komplett andere Ansätze bei der Strukturierung. Bei Projektarbeiten u.ä. kann man die eigenen Erfahrungen dann durchaus auch einbringen (zur Diskussion stellen), sofern sie gut begründet werden können.

Bei einer Vorgabe (durch ein Team/einen Vorgesetzten/bei Einarbeitung in ein bestehendes Projekt) sollte diese erst einmal konsequent befolgt werden.

Für Supportanfragen an andere Entwickler ist es sinnvoll, von bekannten Konventionen nicht zu sehr abzuweichen.

Answer 2

[KarlRanseierIII]

Glaubenskriege bei der Klammerung sind nicht zielführen - Gibt es aber projekt- und unternehmensweite Code-Guidelines, dann sollte man sie natürlich einhalten.

Andererseits gibt es seit Dekaden Codestyler, sodaß zwischen den Styles umgeformt werden kann.

Endkommentare empfinde ich als überflüssig, zumal die meisten Code-Editoren wohl brace highlighting machen sollten.

Answer 3

[jo135]

Völlig egal, in C hat sich nun mal nie ein dominanter Stil entwickelt. In der Praxis passt man sich halt daran an, was im Projekt als Standard definiert wurde. Das Formatieren selbst macht eh der Editor oder ggf. ein Formatter im Pre-Commit-Hook.

Diese "end"-Kommentare sind aber seit mindestens 20 Jahren obsolet.

Answer 4

[apachy]

Weder gut noch schlecht. Wäre nun nicht mein favorisierter Stil. Ich mag die Klammer gerne hinten dran, weil es kompakter ist und 4 Spaces, statt wie hier 6 und den Kommentar brauch ich auch nicht. Heutzutage nutzen wir IDEs mit Syntax Highlighting, die zugehörige Klammer wird markiert, der Quelltext ist meist klappbar, ggf. gibt es sogar verschiedenfarbige Klammern usw.

Ich würde es also wohl so schreiben:

#include <stdio.h>

int main(void) {
    printf("Hello, World!");
    return 0;
}

Zumindest wenn ich für mich programmiere und das nicht Code ist, der schon anders geschrieben ist. Dann passt man sich den Stil dort eben an.

Woher ich das weiß: Berufserfahrung – Softwareentwickler/Projektleiter seit 2012

Comments

[L4ze3]

Heutzutage nutzen wir IDEs mit Syntax Highlighting

Wir benutzen vim unter linux, wo Syntax Highlighting deaktiviert ist

[apachy]

@L4ze3

Ja, so läuft das aber nicht in der Welt da draußen bzw. sehr selten und das nur, wenn man auf Schmerzen steht und unproduktiver arbeiten möchte.

Habt halt ggf. einen Lehrer, für den Betriebssystem, IDE, Code Stil usw. ein wenig eine Religion ist.

Gibt wenige Leute die mit Vim arbeiten und dann meist so vollgestopft mit Plugins und co. dass es genauso mächtig ist wie fast jede andere IDE.

Answer 5

[gutefrage133386]

Ich finde es gut, aber der Kommentar am Ende ist eigentlich unnötig