Streit um automatische Codeformatierung

ten

eigentlich trägt doch jedes teammitglied die verantwortung für seine codes und kann auch selber entscheiden, wie er's formatiert. normalerweise soll auch niemand anders darin herumpfuschen, ausser wenn der typ nicht mehr da ist.
aber dann macht ja jemand anders damit weiter und der formatiert dann eben nach seinem stil...

SideWinder

Ich würde auch sagen: Pech. Aber das muss nicht sein. Bei einer ordentlichen IDE (wie zB Eclipse) sind die Einstellungsmöglichkeiten gut genug um den Firmenstandards optimal angepasst zu werden. Dann wird immer automatisch formatiert und es gibt keine Ungereimtheiten mehr.

Jeder sein eigenes Format kommt sowieso ab einer gewissen Projektgröße (imho) nicht mehr in Frage (auch wenns leider in vielen Projekten Gang und Gebe ist...). Und da rede ich jetzt nicht nur von Formatierungen sondern auch von Methodennamen, Ordnung innerhalb der Klasse, etc.

MfG SideWinder

DEvent

Der Projektleiter setzt doch sowas bei größeren Projekten doch immer fest und jeder muss sich daran halten.

Namenskonventionen, Formatierungen usw.

Marc++us

tfa schrieb:

Wahrscheinlich haben nur wir solche komischen Probleme...

Nein, auf keinen Fall, das sind alltägliche Probleme, leider.

Mein Gesamtprojektleiter (der kein Softwerker ist und verschiedene Gewerke unter sich hat) meinte erst dieser Tage:

Jetzt habt Ihr Softwareleute doch bereits alle Freiheitsgrade, und dann könnt Ihr doch nichts damit anfangen, weil Ihr Euch mit Ideologien befasst.

Da ist was dran.

Im speziellen Fall: es spielt eigentlich gar keine Rolle, ob man den Autoformatter nimmt oder nicht, wesentlich ist, daß es eine einheitliche und verbindliche Festlegung geben muß. Punkt. Letztlich wird sie praktisch keinem gefallen, da bei einer solchen Regel am Ende keiner seinen Lieblingsstil zu 100% findet. So what?

Es gibt ja noch viel schlimmere Dinge in Firmen, z.B. daß Programmierer ihre Variablen englisch bezeichnen, andere in deutsch. Fürchterlich und völlig untragbar.

Ich stimme auch tens Kommentar nicht zu, daß ja ohnehin jeder nur seinen Code liest - ein solches Team verzichtet ja offensichtlich auf den lehrreichen und auch wissenssteigernden Effekt von gegenseitigem Codereading, und arbeitet nicht effizient. Sobald man aber Codereading einführt, sind einheitliche Regeln ohnehin unabdingbar. Ein Verzicht auf Codereading - das ja bei weitem nicht total sein muß, sondern sich auch auf kritische Stellen beschränken kann - senkt letztlich die Qualität des Codes ab. Um sowas einführen zu können ist gegenseitige Lesbarkeit und damit einheitliche Formatierung Grundvoraussetzung.

[Insofern ist dann ein automatisches Tool wieder akzeptabel, wenn danach keine Änderungen von Hand gemacht werden - d.h. jeder kann während seiner produktiven Phase formatieren wie er will, sobald er aber den Code ins CVS einstellt oder zum Codereading freigibt, muß er auf Teamstandard formatiert werden.]

SideWinder

Bei uns war einer dabei, der formatierte den Code nach dem auschecken erstmal auf seine Version um, um ihn beim Einchecken wieder zurück zum Teamstandard zu formatieren. Klappte auch wunderbar, weiß nur nicht mehr wie er das technisch realisiert hatte...

MfG SideWinder

Marc++us

Ist durchaus akzeptabel. Es wird nur dann unsinnig, wenn er nach dem Auschecken und automatischer Formatierung noch von Hand eingreift - denn dann wird's Zeitverschwendung. Aber einfach ein Tool aufrufen lassen wenn man eincheckt/auscheckt ist ja kein Hexenwerk und wird von den IDEs ohnehin unterstützt.

Apollon

Neulich fuehrte ein recht grosser Kunde eine Betriebsbesichtigung bei uns durch. Die Frage nach Codingguidlines wurde auch gestellt.

tfa

SideWinder schrieb:

Ich würde auch sagen: Pech. Aber das muss nicht sein. Bei einer ordentlichen IDE (wie zB Eclipse) sind die Einstellungsmöglichkeiten gut genug um den Firmenstandards optimal angepasst zu werden. Dann wird immer automatisch formatiert und es gibt keine Ungereimtheiten mehr.

Wir benutzen Eclipse. Die Möglichenkeiten der Formatierers sind schon beeindruckend (beeindruckend zahlreich jedenfalls). Aber leider reicht das oft nicht.
Beispiel:

Aus dem recht gut les- und durchschaubaren

zeit[IDX_PRO_WOCHE] = (  getAZG(IDX_SCHICHT1) * getSchichtenAnzahl(IDX_SCHICHT1)
                               + getAZG(IDX_SCHICHT2) * getSchichtenAnzahl(IDX_SCHICHT2)
                               + getAZG(IDX_SCHICHT3) * getSchichtenAnzahl(IDX_SCHICHT3)) / 60.0;

wird nach dem Formatieren

zeit[IDX_PRO_WOCHE] = (getAZG(IDX_SCHICHT1) * getSchichtenAnzahl(IDX_SCHICHT1) + getAZG(IDX_SCHICHT2)
				* getSchichtenAnzahl(IDX_SCHICHT2) + getAZG(IDX_SCHICHT3) * getSchichtenAnzahl(IDX_SCHICHT3)) / 60.0;

Eclipse kann das nicht vernünftig formatieren.
Ein anderes Beispiel sind Methodenaufrufe, deren Parameter zusammengesetzte Ausdrücke sind.
Entweder Eclipse bricht nach x Spalten willkürlich um (und reißt die Parameter auseinander) oder man stellt den Formatierer so ein, dass nach jedem Parameter ein Zeilenumbruch stattfinden. Nur leider macht Eclipse dann aus

x = new Point( 10, 20);

ein ziemlich blödsinniges

x = new Point (
           10,
           20);

Und das will doch auch keiner, oder?
Nochmal: Ich hab nichts gegen Code-Conventions und Autoformatieren. Nur gegen den Zwang diesen immer und überall einsetzen zu müssen. Wenn jemand einen wirklich in allen Fällen funktionierenden Formatter kennt, immer her damit.

Thomas

ten

Marc++us schrieb:

Ich stimme auch tens Kommentar nicht zu, daß ja ohnehin jeder nur seinen Code liest - ein solches Team verzichtet ja offensichtlich auf den lehrreichen und auch wissenssteigernden Effekt von gegenseitigem Codereading, und arbeitet nicht effizient.

eigener formatierungsstil schliesst ja keine reviews etc. aus und die wenigesten werden ihre codes so formatieren, dass andere sie nicht lesen können.
ausserdem, finde ich, mindert es die effizienz eines teams mehr, wenn entwickler den code gegen ihr persönliches empfinden formatieren müssen...

op: wenn ich fremde codes verwerte, lass' ich erstmal den formatierer von 'slickedit' drüberlaufen (das teil ist aber leider keine freeware)...

Jester

ten schrieb:

Marc++us schrieb:

Ich stimme auch tens Kommentar nicht zu, daß ja ohnehin jeder nur seinen Code liest - ein solches Team verzichtet ja offensichtlich auf den lehrreichen und auch wissenssteigernden Effekt von gegenseitigem Codereading, und arbeitet nicht effizient.

eigener formatierungsstil schliesst ja keine reviews etc. aus und die wenigesten werden ihre codes so formatieren, dass andere sie nicht lesen können.
ausserdem, finde ich, mindert es die effizienz eines teams mehr, wenn entwickler den code gegen ihr persönliches empfinden formatieren müssen...

Hierzu nochmal meine Frage: Wie lange? 2 Tage? Ne Woche? Wie unflexibel muß man sein um sich über nen längeren Zeitraum oder gar dauerhaft von solchen Details ausbremsen zu lassen?

ten

Jester schrieb:

Hierzu nochmal meine Frage: Wie lange? 2 Tage? Ne Woche? Wie unflexibel muß man sein um sich über nen längeren Zeitraum oder gar dauerhaft von solchen Details ausbremsen zu lassen?

es nervt einfach.
es ist in etwa so, als wenn man einen linkshänder zwingen würde, mit der rechten hand zu schreiben. und wer genervt ist, macht keine gute arbeit...

SideWinder

Wenns tatsächlich nur um das Code-Format geht würde ich gar nicht lang fackeln und in meinem Stil schreiben und am Schluss vor dem Check-In das Teamformat einbauen.

Methodenbenennung, etc. muss aber einheitlich sein. Alleine schon aus Gründen der API-Usability für andere Leute. Wenn das einmal isOn(), einmal checkOn() und einmal getOnState() heißt dann is jedesmal Doku angesagt...und das sind nur die Kleinigkeiten. Sprachliche Dinge, Kommentartools, etc. sollten alle einheitlich verwendet werden.

MfG SideWinder