Programmier-Prinzipfrage: wie stark Coding Styles automatisieren

[Sholvar]

In unserer Web-Plattform-Schmiede sind wir gerade bei der Überarbeitung unserer Coding Styles. Dabei kann man aus meiner Sicht auf 3 Arten vorgehen. Für welche Variante würdet ihr stimmen, was spricht dafür und dagegen?

(Da es nicht um eine rein technische Frage geht, hab ich sie ins Com gestellt.)

 

[Drey]

da wir mit eclipse entwickeln haben wir folgende automatik

- der codestyle wurde definiert und in eclipse importiert (mit samt fehlernder warnungen bei fehlender dokumentation von public methoden)
- beim Speichern (Save-Actions) wird der code formatiert und weitere styleguide actions aufgeführt

somit wird ins svn nur styleguide konformer code eingecheckt.

Hat Vorteile bezüglich Standardisierung ... meiner Meinung nach wird aber Stellenweise der code unleserlich, wenn in speziellen fällen der styleguide einfach nicht passt

 

[MegaVolt]

Dreys Methode klingt sehr gut. Wenn man nicht mit Eclipse arbeitet wüde ich den Beautifier nehmen (der dann ja nichts anderes macht als die Eclipse styles).
Lesbarer code ist schon was tolles

 

[TheScorpion]

Ich bin nicht der Meinung, dass ein hook/beautifier o.ä. den Job des Programmierers tun sollte.
Viele Wege führen nach Rom und es gibt viele zweckmäßige und lesbare unterschiedliche Formatierungen.
Warum sollte man einem Programmierer das nun auch noch vorschreiben?
Da ja jeder seinen eigenen Stil hat, müsste man bei einem hook ja noch Zeit einplanen, damit der Coder seinen Code an den Willen des hooks anpasst.
Bei Automatismen kann es dazu führen dass, der Style einfach nicht zu der speziellen Situation passt (wie Drey schon schrieb).

Die Mitarbeiter sollten geschult werden, wie man sich allgemein die Formatierung vorstellt. Dies schreibt man in eine TQVA (bzw. deren Anhänge) und gut ist.

 

[MegaVolt]

Original geschrieben von TheScorpion
Ich bin nicht der Meinung, dass ein hook/beautifier o.ä. den Job des Programmierers tun sollte.
Viele Wege führen nach Rom und es gibt viele zweckmäßige und lesbare unterschiedliche Formatierungen.
Warum sollte man einem Programmierer das nun auch noch vorschreiben?

Wenn jeder nur mit seinem eigenen code arbeitet ist das sicherlich richtig so. Aber wenn ich deinen code lesen und bearbeiten muss, dann will ich ihn nicht lange umformatieren müssen bevor ich halbwegs durchblicke.

Mit einem Beautifier kann ich programmieren wie ich will und habe dann einen code im svn, der von allen einfach gelesen werden kann. Klingt doch gut

 

[BiBaButzemann]

beim refactoring hübscher machen?

Spoiler

ok, ich gebs zu, ich refactor auch viel zu wenig

 

[Shihatsu]

ka, wo ihr arbeitet und wie gross eure projekte sind, aber bei uns ists recht einfach:

sun konventionen, NICHTS anderes. das sorgt für lesbaren code, lässt dem jeweiligen coder aber noch genügend freiraum "zur entfaltung". wir haben zb nen typen im projekt, der hat seinen ganz eigenen style - der ist halt selber dafür zuständig, das er vorm upload immer brav umformatiert. wer sich nicht dran hält, kriegt das zeug um die ohren gepfeffert.

 

[TheScorpion]

Nach nem Beautifier hab ich aber so nen Einheitsbrei.
Vllt wollte der Programmierer ja bestimmte Stellen hervorheben oder kann (wenn er selber mal wieder dran sitzt) seine gewohnte Formatierung sehen.
Mir persönlich gefällt auch nicht jede automatische Formatierung und außerdem haben wir hier bei uns auch C-Code, der ist so alt und hingehackt, der hat bisher jeden Beautifier zum Absturz gebracht

Es soll ja nicht jeder machen was er will und Kraut und Rüben programmieren, der Code wird ja nicht unleserlich, wenn ich bei nen IF das AND statt am Anfang der Zeile ans Ende schreibe.

€@Shi: Im Grunde ist das bei uns ähnlich, nur dass es nicht "sun"-Konventionen sind, sondern mehr oder weniger eigene, die mal irgendwo aufgeschrieben wurden.

 

[drwilly]

Es ist doch egal wie die Stilrichtlinien eingehalten werden, solange sie eingehalten werden.

Ich stimme sozusagen für alle Optionen auf einmal:
- Stilrichtlinien erstellen, festhalten, verfügbar machen (-> muss sowieso gemacht werden)
- Einhaltung der Stilrichtlinien z.B. über precommit hook (-> ist sowieso Teil der QS);
- formatierer zur Unterstützung der Programmierer anbieten (-> sinnvoll).

 

[Sholvar]

Ja, ich finde die gebrachten Argumente sehr sinnvoll.
Es gibt aber auch z.B. so eine Situation:
Du hast eine Datei mit x-tausend Zeilen, die sich so im Laufe der letzten y Jahre zsuammen gehackt hat. Sie ist relativ leserlich und gut formatiert.
Nun hat man aber ein Projekt mit anderen indents und anderer Setzung der geschweiften Klammern und ein SVN Repository das nur nach eigenen Standards formatierten Code akzeptiert. Jetzt müsste sich einer ransetzen und für Eclipse nen Formatter schreiben, der nur diese Sachen ändert und alles andere tolerant in Ruhe lässt. Oder man müsste jede Zeile von Hand ummodeln (nicht jeder kann Eclipse überhaupt benutzen, einige ältere Herren nutzen hier nur Joe, Emacs usw).

Genau das möchte ich aber gern vermeiden. Schliesslich sollen die Coding Styles den Programmierer unterstützen - schneller arbeiten lassen - und nicht behindern.

Vielleicht muss man es auch differenzierter betrachten und kann für einige Sachen wie Indentation einen Beautifier benutzen, aber sollte in anderen Punkten (Zeilenlänge, Namensvergabe... soviel fällt mir da eigentlich nicht ein. Beispiele?) darauf verzichten, einzugreifen.

 

[Picard]

# an dave. ist einfach eine art der erziehung

Ich kann ich übrigens das buch "code complete" (->google) von Steven McConnell sehr ans herz legen, einfach ein must read in der branche

 

[Clawg]

Netbeans -> Source -> Format

 

[RRA^StArFiRe]

lesbarer code ist wichtig, aber noch viel wichtiger ist gute modularisierung.
dann ist man erst gar nicht auf den code anderer angewiesen.
oder refactored in nen unlesbaren code bugs rein...

 

[drwilly]

Original geschrieben von Sholvar
Es gibt aber auch z.B. so eine Situation:
Du hast eine Datei mit x-tausend Zeilen, die ...

FAIL

Original geschrieben von =Starfire=
dann ist man erst gar nicht auf den code anderer angewiesen.

Nur wenn du die einzige Person bist die jemals an diesem Modul arbeiten wird.

 

[RRA^StArFiRe]

Original geschrieben von Dr.Willy

Nur wenn du die einzige Person bist die jemals an diesem Modul arbeiten wird.

wenn man nicht die einzige person ist, dann würde ich weiter modularisieren und das design refactorn
ansonsten gilt: vapiss dich aus meinem code!!


im prinzip zwingen einem die style-richtlinien ja zur modularisierung.
mit so schönen einschränkungen wie "komplexität einer methode darf nicht höher als 5 sein".
oder "eine methode darf nicht mehr als 50 operationen haben".
*ich kotz ab!*

 

[ViperDK]

ist ne schwierige frage. einerseits gibt es definitiv stellen an denen nicht-guidelinegerechter code lesbarer ist (heisst nicht umsonst guidelines und nicht rules^^), andererseits gibts genug coder die sie dann auch nicht beachten wo es sinn macht :/

naja alles in allem pro check-in-policy, wenn unser team foundation server mal am start ist und bissl zeit ist (hehe 8[) werd ich wohl auch mal was in der richtung tun.


Das mit der Kommentierung ist dann schon eher so ne Streitfrage. Ich halte den Code lieber kurz und spare mir unnuetze kommentare.

/// <summary>
/// Clears all text
/// </summary>
/// <remarks>
/// You should know, this method clears each and every character in the TextBox. Surprised?
/// </remarks>
public void ClearText()
{
  innerTextBox.Clear();
}

hoehoe

 

[TriloByte]

Also der Standard Formatter in Eclipse saugt ziemlich. Eine einheitliche Formatierung, die überall drüberbügelt ist auch nur bedingt geeignet.

Sauberer Code ist auf alle Fälle wichtig, da würde ich aber nicht bei irgendwelchen Einrückungskonventionen o.ä. anfangen, sondern damit, Methoden mit mehr als 1 Bildschirmseite Code, übergroße Klassen und alles was sonst noch nach Spaghetti aussieht, besser zu modularisieren und undokumentierten Code vernünftig dokumentieren.

Bei PHP sind die PEAR Coding Standards zur Orientierung ganz nett.

 

[Eeth]

wieviele seid ihr denn?
guter codingstyle >> all für wartung, erweiterung etc...

 

[Eeth]

Original geschrieben von Shihatsu
ka, wo ihr arbeitet und wie gross eure projekte sind, aber bei uns ists recht einfach:

sun konventionen, NICHTS anderes. das sorgt für lesbaren code, lässt dem jeweiligen coder aber noch genügend freiraum "zur entfaltung". wir haben zb nen typen im projekt, der hat seinen ganz eigenen style - der ist halt selber dafür zuständig, das er vorm upload immer brav umformatiert. wer sich nicht dran hält, kriegt das zeug um die ohren gepfeffert.

#2