Widersprüchliche Java-Stile in einem Team

12

Ich bin Teil eines Java-Entwicklungsteams mit einer Frist von 6 Wochen. Dies macht es erforderlich, sehr viel Code sehr schnell zu schreiben. Unser Entwicklungsteam hat jedoch unterschiedliche Codierungsstile. Von Namenskonventionen bis zu Abstraktionsmethoden ist in unserem Team alles anders. Kennt jemand irgendwelche Dokumente, die "Standards" für Java diktieren?

Um dies zu verdeutlichen, habe ich mich gefragt, ob es eine Organisation gibt, die beispielsweise die richtige Benennungskonvention für Variablen und Funktionen vorschreibt. Dies ist von größter Bedeutung, da wir es uns bei einer so kurzen Frist nicht leisten können, Zeit zu investieren, um den Code des jeweils anderen zu verstehen.

java coding-standards

— Daniel Gratzer
quelle

18

Es gibt eine solche Organisation: Sun / Oracle selbst. Das Dokument heißt Code-Konventionen für die Java-Programmiersprache und beschreibt die meisten Konventionen, die Sie benötigen. Lassen Sie einfach alle zustimmen, es zu lesen und seinen Empfehlungen zu folgen.

— Andres F.
quelle

3

Dies ist ein bekannter Standard, aber haben Sie keine Angst davor, davon abzuweichen, wo das Team zustimmt. Die Beschränkung auf eine Breite von 80 Zeichen kann beispielsweise schmerzhaft sein.

— Martijn Verburg

1

@MartijnVerburg Das Limit kann zum Umgestalten von Methoden und Klassen führen, um tiefe Einrückungen zu vermeiden.

Dies ist eine Konvention und kann ein vernünftiger Fallback sein, wenn Sie keine eigene Vereinbarung finden, aber wie der Name schon sagt, ist es keine Konvention.

— Benutzer unbekannt

@userunknown Du hast recht. Ich stimme nicht einmal allen Konventionen zu. In Anbetracht des Zeitrahmens des OP ist dies jedoch ein guter Kompromiss.

— Andres F.

8

Ich gehe wirklich auf Andres 'Antwort ein und konzentriere mich auf den Aspekt der einheitlichen Formatierung des Java-Codes.

Wenn Sie Eclipse verwenden, können Sie den Java-Formatierer so einstellen, dass er automatisch den Java-Standard verwendet. Der Eclipse-Formatierer verfügt auch über andere hilfreiche Einstellungen, z. B. die Zeichen pro Zeile (dh wie viele Zeichen pro Zeile, bevor eine neue Zeile umgebrochen wird) und viele andere. Zeichen pro Zeile zu standardisieren macht es einfacher zu DIFF Code von verschiedenen Entwicklern geschrieben , ohne nur eine Menge Unterschiede, die aus Abstand und Zeilenumbrüchen.

Nachdem Sie mit Eclipse alle gewünschten Einstellungen vorgenommen haben, exportieren Sie den Formatierer als Datei, die von jedem Mitglied des Teams importiert werden kann. Wenn Sie also Eclipse verwenden, empfehle ich dringend, alle Optionen zu erkunden, die es automatisch formatiert und für Sie bearbeitet, und die Einstellungen dann für das gesamte Team freizugeben.

Ich würde annehmen, dass die anderen wichtigen Java-IDEs (IntelliJ und Netbeans) eine ähnliche Funktion zum Exportieren der Formateinstellungen haben.

— Sam Goldberg
quelle

2

+1 Gute Antwort auch! Sie können auch ein Plugin wie Checkstyle installieren und sich warnen lassen, wenn Sie Konventionen brechen.

— Andres F.

Das machen wir auch. Einstellungen -> Java -> Editor -> Speicheroptionen und Format beim Speichern aktivieren. Der Hauptgrund ist, sicherzustellen, dass die von einem Format betroffenen Quellzeilen so schnell wie möglich ausgeführt werden, um den Versionskontrollverlauf so sauber wie möglich zu gestalten (es gibt wieder Unterschiede).

Ja, ich habe vor kurzem auch damit angefangen. Das einzige, bei dem ich mir nicht sicher bin, ist, dass ich bei der Speicheroption "Nicht verwendete private Variablen entfernen" ausgewählt habe. Während ich TDD mache, finde ich, dass meine Variablen häufig verschwinden, weil Code gespeichert wurde, bevor ich sie verwendete ... aber abgesehen davon war diese Option großartig.

— Sam Goldberg

6

Dies [verschiedene Arten der Codierung] ist von größter Bedeutung, da wir es uns bei einer so kurzen Frist nicht leisten können, Zeit zu investieren, um zu versuchen, den Code des jeweils anderen zu verstehen.

Tatsächlich. Es ist nicht von größter Bedeutung.

Nach 30 Jahren als Berater habe ich viel Code von vielen Kunden gelesen . Es ist wichtig zu beachten, dass jeder Kunde (und oft auch innerhalb der Organisation eines Kunden) unterschiedliche Stile hat.

Nachdem ich so viele Stile gelesen habe, habe ich das gelernt.

Stil spielt keine Rolle

Bitte konzentrieren Sie sich darauf, Code zu schreiben, der immer funktioniert, und schreiben Sie Unit-Tests, die beweisen, dass er immer funktioniert.

Nachdem Sie den Arbeitscode ausgeliefert haben, können Sie ihn nachbessern, wenn die zu behebenden Fehler und die zu installierenden Verbesserungen aufgebraucht sind.

— S.Lott
quelle

Vielleicht spielt es keine Rolle, aber es ist auch sehr schön zu haben und sehr einfach zu tun.

— Kevin

1

Stil ist egal, aber Konsistenz ist wichtig. Ein inkonsistenter Stil erschwert die Wartung der Software erheblich.

— Jesper

5

@Jesper: "Inkonsistenter Stil erschwert die Wartung der Software ein" kleines bisschen ". Es ist nicht viel schwieriger. Undurchsichtiger, schlechter, fehlerhafter Code ist viel schwieriger zu pflegen. Inkonsistente Stile im Arbeitscode sind nur inkonsistente Stile. Manche Menschen haben einen Akzent, und Sie müssen genauer zuhören. Inkonsistente Stile sind kaum mehr als ein anderer regionaler (oder nationaler) Akzent.

— S.Lott

1

Stil spielt im globalen Sinne keine Rolle, aber konsistenter Stil innerhalb eines einzelnen Teams spielt eine Rolle. Es wird kein Projekt machen oder brechen, aber wenn es genauso einfach ist, konsequent zu sein wie nicht, warum nicht konsequent vorgehen? Ihr Code wird zumindest geringfügig besser sein.

— Bryan Oakley

1

"Ihr Code wird bestenfalls geringfügig besser sein". Und ja, es kostet fast nichts und ist mit Sicherheit risikolos. Aber. 100% Testabdeckung ist weitaus wertvoller als Konsistenz.

— S.Lott,

2

Mach dir keine Sorgen um die Auswahl eines perfekten universellen Standards. Alles, was Sie brauchen, ist, dass Ihr Team einem Standard zustimmt und sich daran hält. Machen Sie sich Ihre eigenen, wenn Sie möchten, aber seien Sie konsequent.

Konsistenz verbessert die Zusammenarbeit, Zusammenarbeit verbessert den Code.

Auch wenn die tatsächliche Konsistenz nicht hilft, ist die Tatsache, dass Ihr Team zusammengearbeitet hat , um eine Einigung zu erzielen, eine gute Sache. Ihre Unfähigkeit, etwas so Einfaches wie Codierungskonventionen zu akzeptieren, lässt darauf schließen, dass möglicherweise größere Teamwork-Probleme unter der Oberfläche lauern.

— Bryan Oakley
quelle

0

Das oben erwähnte Sun Java CC ist nicht nur 13 Jahre alt und einige seiner Regeln sind veraltet (z. B. 80 Zeichen pro Zeile), sondern definiert auch keine Namenskonventionen, mit Ausnahme der allgemeinsten (Kamelgehäuse für Klassen, Großbuchstaben) für statische Endvariablen und dergleichen).

Sie müssen Ihre eigenen Standards für die verschiedenen definieren Arten von Klassen, wie DAOs, EJBs, Organisationen, was auch immer Sie verwenden. Der Sun Java CC ist wie eine abstrakte Basisklasse, die zum Erweitern gedacht ist :)

— MaDa
quelle

Ich bin damit einverstanden, dass Suns Java CC ein bisschen alt ist, aber es ist nur als Ausgangspunkt gedacht. Ich nehme an, das OP hat nicht viel Zeit, um seine eigene CC zu definieren, sonst hätte er das gesagt! (Übrigens, wo ich derzeit arbeite, verwenden sie ein Sonar- Plugin, das so konfiguriert ist, dass es die 80-Zeichen-Beschränkung erzwingt - diese Regel ist also in einigen Läden immer noch gültig und in die Hose geht).

— Andres F.

Lesbarkeit ist neben anderen Gründen ein Faktor. Das Scannen einer langen Strecke über eine Linie ist weitaus weniger effizient als das Scannen nach unten. Mit gut formatiertem Code können Sie schnell über irrelevanten Code scannen.

— BillThor

Wenn Sie Probleme mit 80 Zeichen pro Zeile haben, haben Sie entweder erstaunlich lange Bezeichner oder setzen unleserlich viel auf einzelne Zeilen. Ersteres ist albern (können Sie den Kern nicht auf weniger als das reduzieren?) Und letzteres ist ein Hinweis auf einen dringenden Bedarf an Refactoring. Die automatische Formatierung beim Speichern ist großartig, da Sie sich dann überhaupt nicht mehr um die Formatierung kümmern müssen. Die Software erledigt das für Sie.

— Donal Fellows

@DonalFellows Ja, in der heutigen Zeit soll Sie die Beschränkung auf 80 Zeichen daran erinnern, nicht wegen kleiner Terminal-Bildschirme umzugestalten.

— Andres F.

0

Wie von anderen hier erwähnt, können Sie online nach einem der wenigen populären 'Style-Guides' für Java suchen und alle im Team davon überzeugen, sich an diese zu halten. Einige Tools zur Codeüberprüfung in Ihrer bevorzugten IDE können Ihnen dabei helfen, Sie daran zu erinnern, wenn Sie dies nicht tun.

Manchmal ist jedoch auch Politik involviert. Ich war einmal in einer Situation, in der der leitende Entwickler im Team seine Arbeit fortsetzte, selbst nachdem jemand die Notwendigkeit einer Standardisierung erwähnt hatte. In einer solchen Situation ist es vielleicht besser, seinen Codestil zu beobachten und ihm zu folgen, da er wahrscheinlich über das meiste Wissen über die Codebasis und die Anforderungen verfügt und Sie möglicherweise keine Zeit damit verschwenden möchten, auf die Zehen zu treten, obwohl er schwierig ist. Welches ist, was der Rest von uns in dieser besonderen Situation getan hat und ich folge widerwillig.

Daher ist es wichtig, auch Ihre Situation zu berücksichtigen.

— Schneepolar
quelle

Welches Land ist das? Klingt nach einer kulturellen Sache.

@ ThorbjørnRavnAndersen Er meint damit, dass Menschen sich gegen Veränderungen wehren können, wenn "was sie so lange getan haben". Politisch in diesem Sinne ist nur "Büropolitik"

— Robotnik

0

Onkel Bob zeigt in seinem Buch "Clean Code" einen moderneren und aktuelleren Codierungsstil. Leider enthält es keine Artikelliste. Du musst es lesen. Er sagt sich, dass man seinen Code lesen muss, um seine Konventionen zu sehen. Onkel Bob ist ohne Zweifel eine Art Institution. Das Buch ist ohnehin eine ausgezeichnete Lektüre, also sollten Sie es so schnell wie möglich lesen, auch wenn es zu spät ist, es jetzt zu lesen.

— Peter Kofler
quelle

0

Was im Code wirklich zählt, ist die geringe zyklomatische Komplexität, der geringe Umfang, die hohe Kohäsion und die Auswahl der aussagekräftigen Bezeichner. Unter diesen Umständen ist Code leicht zu verstehen und gut.

Ich schlage vor, Sie werfen einen Blick auf die spartanische Programmierung .

In den meisten Codierungsstandards wird beschrieben, wie Sie schlecht geschriebenen Code hübsch aussehen lassen, und in den meisten Diskussionen über den "Codierungsstil" geht es eigentlich um die Formatierung. Bei der Code-Formatierung wird die Struktur Ihres Codes visuell dargestellt. Es ist trivial und automatisierbar und hat mit dem Codierungsstil kaum etwas zu tun, da es beim Codierungsstil nicht darum geht, wie Sie die Codestruktur darstellen, sondern darum, wie Sie den Code strukturieren.
Es gibt auch eine Menge religiöser Kriege um Namenskonventionen, obwohl sie eigentlich nur ein Hack sind, um schlechtes Design zu umgehen. Ein Name ist gut, wenn er sagt, was er bedeutet. Je kleiner und übersichtlicher Ihre Bereiche sind, desto einfacher ist es, einen solchen Namen zu wählen.

— back2dos
quelle