Codingstyle Entscheidung

[xmxanuel]

Idee: alle konfigurieren ihre IDE entsprechend den Codingstyle

[orangeglutton]

So einen Formatter zu haben wäre schon gut, welchen wir verwenden hängt von der IDE ab nehme ich mal an. Was ist der Konsens dazu?

Ich bin für etwas, das einen gleich daran erinnert, Kommentare beim Entwickeln zu schreiben. Kann ja jeder selber beim Entwickeln ausschalten, wenn er da puristisch rangehen will, aber der gepushte Code sollte ordentlich sein. Checkstyle für Eclipse macht das bei mir in der Arbeit so. Was meint ihr?

[xmxanuel]

Ein alternativer Ansatz, welcher in manchen OpenSourceProjekten verwendet ist, dass man sogut wie gänzlich auf Kommentare verzichtet . Wodurch man die Entwickler zwingt sprechende Funktions und Variablennamen zu verwenden. Wenn man Kommentare schreibt heißt das in der Regel, dass man etwas zu kompliziert gelöst hat bzw. nicht sprechenende Variablennamen verwendet hat.

[orangeglutton]

Ich glaub ich wuerde mich erstmal bisschen umgewoehnen, aber im Eclipse-Plugin-Developement-Umfeld sind aussagende Variablennamen halt so Monster wie SelectionOutlinePropertiesListenerAdapterFactory. Da ist ein Kommentar oft besser.

Hier ist es ja anders, und wenn wir die einzelnen Komponenten gut aufteilen und auch die Interoperation gut dokumentieren wird eine extensive Dokumentation auch nicht nötig. (?) Ich bin auch für minimale Kommentare offen. Code Formatting würde aber dann trotzdem gemacht, oder?

[Philip-The-Developer]

Einen vollkommenden Kommentarverzicht halte ich für wenig sinnvoll. Ich finde man sollte mindestens zu Beginn enes jeden Dokumentes Sinn und Zweck desselben dokumentieren, sodass jeder sofort weiß (auch nach 3 Monaten noch) was sich in diesem befindet. Sich jedesmal durch Klassen/Funktionsnamen durchzuwurchteln, um zu erraten was genau da jetzt passiert, halte ich für einen unnötigen Zeitaufwand, den man vermeiden könnte.

Das hält ja auch keinen davon ab seine Variablen trotzdem sprechend zu benennen :)

[xmxanuel]

Ich finde auch, dass man Kommentare verwenden sollte, ganz ohne kann schon schwierig werden. Man sollte aber klug damit umgehen und es ist natürlich sehr viel schöner wenn der Code so programmiert wird, dass dieser selbsterklärend wird.

[lhochstetter]

Einheitliches Codestyling: gerne

Kommentare: ja, wie und in welchem Umfang sollte man dynamisch entscheiden ... eine foreach Schleife, die einfach nur to_string auf Objekten aufruft ist nicht unbedingt "kommentarwürdig", aber eine kurze "Einführung" für jede Datei klingt gut

Variablen / Funktionsnamen: gehören einheitliche Benennungen auch in den Bereich des Codestylings? Ansonsten würde ich vorschlagen, dass wir uns auf einheitliche und halbwegs kurze Bezeichnungen für Funktionen u.ä. einigen ...

[ottne]

Allgemein bei Kommentaren würde ich sagen: je weniger, desto besser, aber auch nicht ganz ohne. Man ist manchmal eben einfach dazu gezwungen, etwas unklare Code-Passagen zu schreiben; dann ist ein Kommentar eine gute Lösung, um die Klarheit zu bewahren.

Die Kommentare wollten wir in englischer Sprache verfassen, oder?

Weitere Fragen fallen mir noch ein:

• müssen wir jedes Feature, das C++ anbietet, auch unbedingt benutzen, oder schließen wir Features eventuell bewusst aus?
• welchen C++ Standard benutzen wir? Momentan scheint C++14 der aktuelle Standard zu sein, ist aber im Vergleich zu C++11 noch nicht so richtig "angekommen". Dann wäre C++11 vermutlich die sinnvollste Option.
• Aus obiger Frage ergibt sich automatisch die Frage nach der Wahl richtiger Compilersettings, wobei CLion einen da möglicherweise auch unterstützt.

Bei Formatierung könnte ich mir einige Regeln/Fragen vorstellen:

• Tabs sind 4 Whitespaces, Curly Brackets bekommen eine eigene Zeile.
• Wie ist das mit Namenskonventionen? Camel Case oder Underscores zwischen Wörtern? Evtl ungarische Notation?

[tobiasschuelke]

Ja, Kommentare wollten wir auf englisch schreiben. Wie genau meinst du das mit den Features? Ich denke das kommt auf die Situation an oder?

Zur Formatierung: Da können wir sehr viele Einstellungen in Clion verändern(File -> Settings -> Editor -> Code style -> C/C++). Das hat den Vorteil, dass wir den Text dann nach diesen Regeln automatisch formatieren lassen können (mit Ctrl + Alt + L). Das sollten wir dann einfach vor jedem Commit machen. Ich finde die vorgegebenen Einstellungen für C++ in Ordnung.

Namenskonvention bin ich für Camel Case und gegen die ungarische Notation.

[ottne]

Dann nehmen wir die Java-Konventionen zur Benennung inkl. der Standard Einstellungen von CLion und der Rest ergibt sich.

Falls keiner mehr Einwände hat, kann man den Issue jetzt schließen.

[lhochstetter]

Welche Java Konventionen meinst du genau?