Code Style

[mbmueller]

Ich habe es in einem anderen PR schon einmal kurz angesprochen, dass wir aktuell nicht wirklich Code Style Guidelines haben. Das führt dann insbesondere dazu, dass Variablen teils nicht intuitiv benannt sind (und insbesondere oft nur aus 1-2 Buchstaben bestehen). Dies erschwert die Lesbarkeit des Codes erheblich.

Was sind da eure Gedanken zu? Sollte man sich da für zukünftige PRs auf ein paar Guidelines festlegen?

[tolot27]

Obwohl ich noch nicht aktiv hier mit entwickle (da noch zu viel mit unserem Verein beschäftigt), empfehle ich das sehr. Ich hatte in einem anderen Projekt mal ein paar Gedanken dazu geäußert und partiell umgesetzt.

[lenilsas]

Ich komme mit dem aktuellen Code style gut zurecht da es meistens die gleichen Variablen sind die nur einen oder zwei Buchstaben haben (m für Mitglied, b für Buchung etc.). Das ganze Projekt zu ändern wäre ein immenser Aufwand. Und es ist die Frage, ob es nicht verwirrend ist, wenn wir es in einer Datei mal mit einem Buchstaben und mal, zB. durch ein PR geändert, ausgeschriebene Variablennamen haben.

[JohannMaierhofer]

Grundsätzlich finde ich es natürlich richtig selbst erklärende Namen zu verwenden.
Allerdings finde ich es kein Problem wenn man z.B. für einen Iterator oder in einer Schleife die Abkürzung benutzt. Sie kommen ja oft nur wenige Zeilen später vor und da ist ja noch die Definition sichtbar.
Daher habe ich auch kein Problem mit dem derzeitigen Stil.
Aber Variablen die im ganzen File verteilt wieder benutzt werden sollten selbst erklärend sein.

[mbmueller]

Ich würde einfach schon existierende Code Style Guidelines zu verwenden. Bspw: https://google.github.io/styleguide/javaguide.html von Google

[lenilsas]

Ich hab das Dokument durchgeschaut. Fast alles davon setzen wir so oder so ähnlich um, das ist ja auch im Formatter definiert. Das keine einzelnen Buchstaben als Variablennamen verwendet werden sollen steht da auch nicht. Was wir jedoch ziemlich vernachlässigt haben sind die Javadocs.

Ich finde wir sollten vielmehr definieren wie die Struktur der Pakete und Klassen ist. Was steht in Actons, was in Views und Controlls? Da fände ich ein einheitliches Vorgehen und eine einheitliche Benennung der Klassen hilfreich.

[tolot27]

Ich sehe immer wieder in PRs inkonsistente code styles, z. B. ifs oder die (Nicht-)Verwendung von Leerzeichen. Der Formatter scheint also nicht immer Anwendung zu finden. Gerade bei neuem Code halte ich das jedoch für sinnvoll.

Dann ist mir noch aufgefallen, dass die Paketnamen auch nicht dem Standard folgen (siehe Naming a Package). Sie sollten komplett kleingeschrieben sein. Verschiedene Code Analyse/Optimierungstools sind da sehr empfindlich und es kann auch ein Plattform-Problem werden, da Windows case-insensitive und Linux case-sensitive Dateisysteme verwenden. Noch scheint es zumindest bei diesem Projekt unproblematisch zu sein.

[dippeal]

Meine Meinung zum Thema:

1. Solange der Eclipse formatter nicht gegen etwas anderes abgelöst wurde ist dieser zu verwenden: https://github.com/openjverein/jverein/blob/master/eclipse/jvereinformatter.xml
2. Dies ist ein opensource Projekt welches historisch gewachsen ist. Freiwilligen Ehrenamtlern einen bestimmten codingstyle aufzuerlegen weil man persönlich die ausgeschriebenen Worte besser findet als Abkürzungen oder Buchstaben für Variablennamen ist anmaßend
3. Eine Dokumentation, von komplexen Quellcode-Abschnitten, innerhalb des Codes ist viel wichtiger als diese Diskussion

[tolot27]

Ich schlage vor, die CONTRIBUTING.md entsprechend um den Formatter zu ergänzen. Außerdem könnte man noch den Formatter über eine GitHub Action mittels Checkstyle for Java aktivieren. Dann bekommt man bei einem PR gleich angezeigt, falls noch Formattierungsbedarf besteht.

[tobidope]

Bei einer Umstellung auf Maven könnten wir spotless oder formatter-maven-plugin einbinden. Damit kann man schnell die Dinge geradeziehen. Wenn sich alle commiten, kann man sogar den build brechen lassen, wenn es nicht korrekt formatiert ist. Das ist allerdings eine potenziell konfliktbehaftete Lösung.

[tolot27]

Wollen wir den Formatter noch erweitern, so dass wir auch konsistente Klammersetzung von '[]' und '{}' haben?