Aufruf zum sauberen "Coden"

Bis zum kompletten Ende des Schlüsselworts einzurücken hat meist den Riesennachteil, dass irgendwann die Zeilen auch ein Ende haben, gerade wenn Blöcke mehrfach geschachtelt werden müssen.

Zitat

Original von wirbel
Bis zum kompletten Ende des Schlüsselworts einzurücken hat meist den Riesennachteil, dass irgendwann die Zeilen auch ein Ende haben, gerade wenn Blöcke mehrfach geschachtelt werden müssen.

Wohl wahr , abba es ist in der Tat die einfacher erkennbare Struktur .
Ich hatte auch schon code , den ich mir auf A4 quer ausgedruckt habe , um alles zu sehen und zu blicken , was da abgeht ...
Der Progger von heute braucht halt n 19 Zöller im 1200*1600 Querformat

HJS

Na super. *lol*

Zitat

Original von wirbel
Na super. *lol*

Ebent

Ne andere Variante wäre in übel verschachtelten Strukturen , die einzelnen "Schachteln" als Functioncalls zu realisieren - was aber wieder zu wildem Screenswitching führt , wenn du die sehen willst ...

HJS

Um mal das Haupt-Thema wieder aufzugreifen:

- Guidelines

Meine Erfahrung:
Es ist schwer, einen umfangreichen Styleguide in mehr als 2 Köpfe zu "drücken". Aber das ist mesitens auch gar nicht notwendig! Meist ist mit einigen wenigen, aber grundlegenden Regeln schon sehr viel erreicht!

Sprich: KISS - am besten erstmal mit (relativ) unstrittigen und nachvollziehbaren Regeln starten, bevor es in Geschmackssachen wie Tab||Space, Position von öffnenenden||schließenden Tags oder der Größe des Einzugs geht!

Kleines Beispiel:
Benennung der Variablen (s. weiter oben: Groß-/Kleinschreibung) - Wenns da doch ne "Regelmäßigkeit" gibt, was spricht dagegen, diese als Regel zu formulieren? Sicher, es wird immer wieder Code geben (nicht zuletzt der bestehende), der nicht zu der Regel passt, aber über die Zeit sollte sich das einpendeln, oder?

Greets!

PS: Fast schon ein Wort zum Sonntag

Zitat

Original von kls

Genau. Ich verstehe auch ehrlich gesagt nicht, was daran so schlimm ist, wenn man alles zusammen übersetzt. Sicher, während einer Entwicklungsphase kommt das wohl häufig vor, und leider hat diese Phase nunmal wesentlich länger gedauert als ich mir das gewünscht hätte. Aber ich fürchte, es wäre ein unverhältnismäßig hoher Aufwand, alles so "abzuschotten", daß verschiedene Program- und Pluginversionen zusammen funktionieren. Da ist es doch wesentlich einfacher, einfach alles zusammen zu übersetzen.

Klaus

Ich meine, dass die jetzigen Abhängigkeiten die Hürde für einen Einsteiger so hoch legen, dass er meist schon absäuft, bevor er mit der Umsetzung seines Dreizeilers begonnen hat. Denkt einfach mal darüber nach, was man alles tun muss um z.B. innerhalb eines standardmässig installierten c't-VDR sein Plugin so zu übersetzen, dass es zu den vorhandenen Binaries passt. Und wenn man's dann fertig hat und vorstellen will, kann ein Grossteil der potentiellen Anwender nix damit anfangen, weil es kein fertiges Binary-Paket für ihre Dispri. x VDR-Version x Patchlevel gibt. Damit bleiben viele Gute Ideeen schon im Ansatz stecken oder sterben gleich nach ihrer Geburt. Das finde ich schade. Eine Dispri. wie Debian würde überhaupt nicht funktionieren, wenn es dort vergleichbare Abhängigkeiten gäbe (jedes Binary-Paket für jede Kernel/Patch-Version).
Guckt Euch mal die Pluginliste im Wiki an. Da sind jetzt schon über 200 gelistet und bis dahin hat es sich lange nicht jedes geschaft. Wie viele davon sind in den grossen Distris. enthalten...?

Zitat

Original von BigDiSt
Um mal das Haupt-Thema wieder aufzugreifen:

- Guidelines

Meine Erfahrung:
Es ist schwer, einen umfangreichen Styleguide in mehr als 2 Köpfe zu "drücken". Aber das ist mesitens auch gar nicht notwendig! Meist ist mit einigen wenigen, aber grundlegenden Regeln schon sehr viel erreicht!

Sprich: KISS - am besten erstmal mit (relativ) unstrittigen und nachvollziehbaren Regeln starten, bevor es in Geschmackssachen wie Tab||Space, Position von öffnenenden||schließenden Tags oder der Größe des Einzugs geht!

Kleines Beispiel:
Benennung der Variablen (s. weiter oben: Groß-/Kleinschreibung) - Wenns da doch ne "Regelmäßigkeit" gibt, was spricht dagegen, diese als Regel zu formulieren? Sicher, es wird immer wieder Code geben (nicht zuletzt der bestehende), der nicht zu der Regel passt, aber über die Zeit sollte sich das einpendeln, oder?

Greets!

PS: Fast schon ein Wort zum Sonntag

Alles anzeigen

Jede Nomenklatur ist besser als keine! Jeder Codestyle hat seine spezifischen Vorzüge und seine Nachteile! Man trefflich und lange über die kleinsten Details streiten. Letztlich sollte aber jedem klar sein, dass in einem grösseren Projekt die Reibungsverluste ins unendliche steigen, wenn sich nicht alle an gewisse Grundregeln halten. D.h. letztlich, sie müssen 'einfach' festgelegt werden! Sich wirklich endlos darüber zu streiten, ob man nun mit Tabs coded oder ohne und wie tief einzurücken ist, ist Kindergratenniveau! Ich habe diese Spielchen in meinen Projekten dadurch beendet, dass Sourcen nur noch 'gebautified' in die Archive dürfen.
Ansonsten ist dass, was 'gute' Software ausmacht nicht formal begründbar. Auch bei Einhaltung noch so vieler Regeln folgt daraus am Ende nicht zwangsläufig qualitativ hochwertige Software.

Ging die Diskussion genau in die Ecke, an die ich dachte

arghgra

Hallo,

eine derartige Diskussion finde ich sehr begrüßenswert. Ich bin seit 15 Jahren als Softwareentwickler bei Siemens tätig und habe in den verschiedensten Projekten gearbeitet, angefangen von kleinen Projekten in einem Team von 2-3 Personen bis zu einem Groß-Projekt mit ca. 5000 Entwicklern weltweit.
Wenn es Probleme bei einem Projekt gegeben hat, dann waren es meist dieselben Ursachen.

Nun zu diesen Thread.
Den Aussagen von arghgra, Urig, wirbel, Dieter, Scorp, BigDiSt und habichthugo kann ich voll zustimmen.
Was den Programmierstil betrifft, bin ich der Meinung, dass es nicht nur einen "einzig wahren und richten Stil" gibt. Da kann man geteilter Meinung sein und jeder hält seinen Programmierstil für den besten.
Dennoch gibt es ein paar grundsätzliche Dinge, die wahrscheinlich von den meisten befürwortet werden (z.B. Kommentare, sinnvolle/sprechende Namen für Variablen, Methoden, ...)

Ich persönlich finde folgende Variante am übersichtlichsten, und ich könnte auch begründen warum. Aber das ist - wie gesagt - Geschmackssache.

while(condition)
{
   statement1;
   statement2;
}

Der Codereview ist bei uns in der Firma eine bewährte Technik, die in den meisten Projekten erfolgreich praktiziert wird.

Ein weiterer Punkt, der mir mindestens genau so wichtig erscheint wie der Programmierstil, ist die generelle Vorgehensweise.
Hat sich schon einmal jemand Gedanken darüber gemacht, wie viele Threads sich mit neuen Versionen von Vdr, Programmen, Plugins, Patchen und den daraus resultierenden Problemen befassen. Wann immer eine neue Vdr-Version freigegeben wird, zieht das einen riesigen Rattenschwanz nach sich. Jedes Plugin muss neu kompiliert werden, viele Plugins müssen auch angepasst werden. Patche müssen angepasst werden, ...

In diesem Sinne,
Christian

was das formatieren/ausrichten von Code angeht, sollte man KEINE Vorschriften machen.
Es macht eh jeder es so wie er es am besten lesen kann.
Sicher haben sich da schon ein paar Stils durchgesetzt(http://de.wikipedia.org/wiki/Einr%C3%BCckungsstil)

Damit ich es besser lesen kann, benutze ich mein eingenen "indent" Stil.
Kann man in fast jede IDE einbauen und per Knopfdrück starten, danach ist der Code in deinem gewohnten Stil formatiert. Habe damit also kein Problem wenn es jemand anders macht.

Mein Stil entspricht in etwa "1TBS"

Was das benennen von Klassen und Variablen angeht, richte ich mich immer nach der Gestalten des Projektes an dem ich gerade arbeite. Mache es also bei VDR so wie Klaus auch.

Mein Stil ist ähnlich dem "K&R" Stil, natürlich mit einigen Anpassungen an persönliche vorlieben - was die Erweiterung des Stils auf C++ angeht setze ich bei TopLevel-Elementen (class, struct, namespace) die öffnende Klammer in die nächste Zeile.

Was die Benennung angeht richte ich mich natürlich (zumindest im Beruf eigentlich selbstverständlich) auch nach den Projekten an denen ich mitarbeite, wobei ich mit Sicherheit auch dort eine eigene Note hinterlasse (denke, das ist immer so).

Was VDR-Plugins angeht muss ich allerdings sagen folge ich nicht dem "Projekt-Stil", was aber nicht an dem Stil an sich liegt, sondern primär daran dass C++ so etwas wie Berufung für mich ist. Ich mag diese Sprache, ich mag den Standard und ich mag die Tatsache, dass sich alles trotz des relativ hohen Alters immer noch rege weiterentwickelt. Da VDR der einzige Bereich ist wo ich momentan in meiner Freizeit groß C++ programmieren kann, möchte ich da natürlich gern auch meinen Stil "leben"

kennt jemand ein indent tool das mit Shell Scripten umgehen kann?

Ich habe hier einen haufen Scripte die alle sehr merkwürdig eingerückt sind.
Auch sehr oft Tab und Spaces gemischt.
Bei C/C++ würde ich astyle drüber laufen lassen.

Finde aber nichts das mit Shell Scripten umgehen kann.