# Programmierstil



## Inuriel (10. Jan 2012)

Hey,

Ich habe eine Frage zum Programmierstil bei KarelJ, zeugt es vom "schlechten" Programmierstil, wenn hinter einer Bedingung if() direkt das kommt, was dann gemacht werden soll? Das sieht in etwa so aus:


```
if(a == b) a=a+b;
```

Oder ist das Wurst? Das würde mein Programm nämlich deutlich kürzen und meiner Meinung nach übersichtlicher machen ...

LG Inuriel


----------



## XHelp (10. Jan 2012)

Code Conventions


> Note: if statements always use braces {}. Avoid the following error-prone form:
> if (
> 
> condition) //AVOID! THIS OMITS THE BRACES {}!
> ...



Aber solange du nicht in einem Team entwickelst oder dein Code veröffentlichen willst, sind es eher Richtlinien.


----------



## emailundlos (10. Jan 2012)

An einigen Stellen in der source code wird ebenfalls so programmiert, aber dann wird zumindest eingerückt und eine Leerzeile eingefügt.


----------



## Firephoenix (10. Jan 2012)

Und spätestens wenn jemand den Code mal ändert und sowas entsteht:


```
if(a == b) a=a+b;
a *= 2;
```

Kann man sehr schnell überlesen dass hinter der abfrage noch etwas gemacht wird.
Und nur weil Code wenig Zeilen hat muss er nicht besser werden.
Bei gutem Code sollte man die Struktur beim ersten überfliegen erkennen können, dazu gehören Einrückungen, passende benennungen und ein entsprechend konstanter Formatierungsstil.

Gute Lektüre zu dem Thema ist übrigens das Buch Clean Code.

Gruß


----------



## knoppers (10. Jan 2012)

Inuriel hat gesagt.:


> Hey,
> 
> Ich habe eine Frage zum Programmierstil bei KarelJ, zeugt es vom "schlechten" Programmierstil, wenn hinter einer Bedingung if() direkt das kommt, was dann gemacht werden soll? Das sieht in etwa so aus:
> 
> ...



Schreib dann doch gleich so.

a = (a==b) ? (a + b) : a;

Aber wie meine Vorredner schon gesagt haben, dies führt irgendwann zu Verwirrungen.
Mann sollte Klasse, bzw. Methoden mit so etwas nicht kürzen. Wenn man sein Code unbedingt kürzen will, dann sollte man sinnvolle Klassen-, bzw. Methodenstrukturen aufbauen. Dies würde sich eh einfacher testen (UnitTests) lassen.


----------



## ARadauer (10. Jan 2012)

Inuriel hat gesagt.:


> zeugt es vom "schlechten" Programmierstil, wenn hinter einer Bedingung if() direkt das kommt


Ich finde es nicht schön


----------



## bygones (10. Jan 2012)

Inuriel hat gesagt.:


> Das würde mein Programm nämlich deutlich kürzen und meiner Meinung nach übersichtlicher machen




```
if(a == b) a=a+b;

if(a == b) {
 a=a+b;
}
```
whau ja... deutlich. 

Ich wuerde mir es nie angewoehnen und sehe es auch nicht sehr gerne. Wie Firephoenix schon geschrieben hat, das Gefahrenpotential ist zu gross.

Wenn ein Programm "zu lang" ist dann ist ganz bestimmt nicht die Klammersetzung bei den ifs das Problem !


----------



## Landei (10. Jan 2012)

Ich habe mich über den blocklosen if-Stil ausgerechnet in "Clean Code" auch erst geärgert. Allerdings habe ich festgestellt, dass da wirklich selten ifs und fors mit mehreren Zeilen vorgekommen sind. Ähnlich ist es bei mir selbst in Scala, wo ich auch selten Blöcke in ifs verwende (wobei dort ifs etwas anders funktionieren, und fast immer einen else-Zweig haben). 

Ich würde also schließen, dass _wenn man es wirklich schafft, dass im eigenen Code nach der Bedingung fast immer eine einzelne Anweisung steht_, der blocklose Stil OK ist, aber _nur_ dann.


----------



## Gast2 (10. Jan 2012)

Ich finds nicht gut und unsere Firmeninternen Code Conventions sehen auch immer Klammern vor. Auf Nummer sicher sag ich da nur. 

Zumal das ganze Ausführungstechnicsh eh wurscht ist, da das ja alles wegoptimiert wird. Schneller wird das Programm dadurch eh nit!


----------



## ARadauer (10. Jan 2012)

Landei hat gesagt.:


> wenn man es wirklich schafft, dass im eigenen Code nach der Bedingung fast immer eine einzelne Anweisung steht


Ich habe Clean Code auch gelesen, frage mich aber, ob das wirklich ist was man will. Ich finde dadurch fragmentiert man gewisse Abläufe zu sehr...


----------



## maki (10. Jan 2012)

ARadauer hat gesagt.:


> Ich habe Clean Code auch gelesen, frage mich aber, ob das wirklich ist was man will. Ich finde dadurch fragmentiert man gewisse Abläufe zu sehr...


Wieso fragmentieren?

Methoden müssen selten länger als 1-3 Zeilen sein...


----------



## Inuriel (11. Jan 2012)

Vielen Dank für die vielen verschiedenen Meinungen. 

Ich werde mich wohl erst entscheiden, wenn mein Programm vollständig ist. Zum größten Teil sind die ganzesn ifs nämlich nur eine Zeile lang und es gibt nur wenige Ausnahmen. Aber ob es dann wirklich meinen Programmcode übersichtlicher macht, sehe ich erst, wenn es vollendet ist.


----------



## xehpuk (11. Jan 2012)

Ich schreibs am liebsten ohne Klammern und mit Zeilenumbruch:

```
if (condition)
    statement;
```
Nur wenn ein if-else-Salat folgt oder das Statement selbst weitere Programmflusssteuerung enthält, nehme ich Klammern zuhilfe.


----------



## knoppers (11. Jan 2012)

Inuriel hat gesagt.:


> Vielen Dank für die vielen verschiedenen Meinungen.
> 
> Ich werde mich wohl erst entscheiden, wenn mein Programm vollständig ist. Zum größten Teil sind die ganzesn ifs nämlich nur eine Zeile lang und es gibt nur wenige Ausnahmen. Aber ob es dann wirklich meinen Programmcode übersichtlicher macht, sehe ich erst, wenn es vollendet ist.



Falsch!!!!!!!!!!!!!

Tut dir selbst, bzw. dem Projekt den Gefallen und entscheide es vorher.
Es ist zwar deine Sache. Aber lieber gleich von Anfang an Ordentlich, bzw. Einheitlich.
Danach anzufangen und das ganze umzubauen, dies kann man bei Testprojekten usw. tun.
Aber nicht bei einem richtigen Projekt. Überlege dir dies lieber vorher.


----------



## irgendjemand (11. Jan 2012)

persönlich finde ich sowohl die diskusion über dieses thema schwachsinn wie auch die mal irgendwann eingeführten conventions und das ständige "drauf-verlinken" ...

wenn man sich mal einen großteil des src.zip aus dem aktuellen 7u2 ansieht sieht man leider auch einfach zu oft das von den java-entwicklern selbst diese conventions ignoriert finden ...

wie oft lässt sich denn in den "offiziellen" source-files sowas finden


```
if(condition)
	statement;
//...
```

persönlich denke ich : wenn sich schon diejenigen die das entwickeln und daran jeden tag weiterarbeiten ihre eigenen "richtlinien" über den haufen werfen ... warum sollte man sich dann als customer noch mit sowas herumschlagen ?


----------



## Andi_CH (11. Jan 2012)

maki hat gesagt.:


> Methoden müssen selten länger als 1-3 Zeilen sein...



Wie will man damit


```
public static void main(String[] args) {
	System.out.println("Hello World");
}
```

etwas vernünftiges prgrammieren können? Da hat ja nicht einmal eine "if-Schleife" Platz drin (Es sind 3 Zeilen)

Ok, vielleicht zählst du ja nur den Inhalt  aber was soll man mit dem folgendn 5-Zeiler vernünftiges programmieren können?


```
public static void main(String[] args) {
	if (draussenHell()) {
		System.out.println("Guten Tag");
	} else {
		System.out.println("Gute Nacht");
	}
}
```

Methoden mit 3 Zeilen sind die absolute Ausnahme (nö nö nö - ich rede nicht nur von mir, denn ich kann ja angeblich nicht programmieren)

3 Zeiler sind genau so wie >>300 Zeiler in Frage zu stellen.

Über >>300 Zeiler muss ich mich nicht äussern, aber das Risiko von 3 Zeilern ist einfach das, dass es irre tiefe Aufrufsequenzen gibt und man sehr schnell den Überblick verliert. ("Sobald ich mehr als 3 Zeilen habe, Subroutine basteln" ist wohl kaum die richtige Philosophie)

Kein schlechter Massstab ist der Bildschirm. Wenn eine Prozedur da drauf Platz hat, ist sie ok, aber nur deswegen einzelne Zeilen zu sparen und keinen Kommtar zu schreiben ........ (no comment)

Zum Thema if - Dank der Tatsache, dass die erste { ja auf Höhe des ifs gescreiben wird, ist der "Zeilenverlust" durch die {} gar nicht so tragisch. In 90% aller Fälle schreibe ich sogar bei 1 Zeiligen ifs die {} hin, obwohl das Ctrl-A , Ctrl-I (automatisches Einrücken) längst zum Reflex geworden ist und das Finden von solchen Fehlern massiv vereinfacht.


----------



## Landei (11. Jan 2012)

Eine feste Zeilenzahl ist ja nicht vorgegeben, die Frage ist immer, ob sich die Methode sinnvoll unterteilen lässt. Es gibt sicher Methoden mit zwanzig Zeilen, wo nichts aufzuteilen oder zu vereinfachen geht (etwa weil bestimmte Daten an einem vorgegebenen Objekt gesetzt werden müssen), und Methoden mit acht Zeilen, die unbedingt aufgebrochen werden müssen. Man sollte es nicht übertreiben, aber die meisten Programmierer sind viel zu unkritisch bezüglich der Methodenlänge. Aber um die Länge geht es ja eigentlich nicht, sondern um Vermischung von Aufgaben, Zuständigkeiten und Abstraktionsebenen. Was ich z.B. _immer_ zu vermeiden suche, sind Methoden, die sowohl Seiteneffekte wie auch einen Rückgabewert (komplizierter als boolean, was eventuell noch akzeptabel ist) haben.


----------



## maki (11. Jan 2012)

> Methoden mit 3 Zeilen sind die absolute Ausnahme (nö nö nö - ich rede nicht nur von mir, denn ich kann ja angeblich nicht programmieren)


Solltest dir mal bessere Vorbilder suchen...

Auch an dich die Empfehlung das Buch "Clean Code" von Bob Martin mal zu lesen


----------



## bygones (11. Jan 2012)

irgendjemand hat gesagt.:


> persönlich denke ich : wenn sich schon diejenigen die das entwickeln und daran jeden tag weiterarbeiten ihre eigenen "richtlinien" über den haufen werfen ... warum sollte man sich dann als customer noch mit sowas herumschlagen ?


das Fehlverhalten anderer als Grundlage zu nehmen ist aber ebenso falsch.

aber - wenn in einem programm das einzige diskutierbare die Klammerung der ifs sind, so ist das mehr als nichtig. Somit - wenns jemand nutzt finde ich persoenlich schlecht, aber nicht Weltuntergangstag



> etwas vernünftiges prgrammieren können? Da hat ja nicht einmal eine "if-Schleife" Platz drin (Es sind 3 Zeilen)


es ist eine Zeile.... es geht um den Inhalt einer Methode. Und wenn man auf der Zahl 3 an sich nun rumdonnert hat man den Sinn der Aussage makis nicht verstanden


----------



## Firephoenix (11. Jan 2012)

Landei hat die Aussage auch passender auf den Punkt gebracht denke ich.
Oft (nicht immer) sind lange Methoden ein Indikator für Überfunktionalität die man in mehrere Funktionen aufbrechen sollte.

Ein krasses Gegenbeispiel wäre z.B. sowas wie ein Dijkstra auf einer Tilemap.
Die Methode kann mit relativ wenig Auslagerung gut in 1-2 Methoden untergebracht werden ohne an Lesbarkeit zu leider oder zuviel Funktion zu bieten - trotzdem wird sie in Java die 3 Zeilen sicherlich sprengen  - allerdings bietet die Methode trotzdem nur eine Funktion : Karte und Standorte/Ziel rein -> Weg raus

Gruß


----------



## maki (11. Jan 2012)

> Oft (nicht immer) sind lange Methoden ein Indikator für Überfunktionalität die man in mehrere Funktionen aufbrechen sollte.


Dass Methoden zu lang sind zeigt sich oft durch Inline-Kommentare, temporäre Variablen, schwierigkeiten einen passenden Namen zu finden, etc. pp.

Methoden sehr kurz zu halten hat viele Vorteile, zB. fürs Refactoring, SoC, SRP, etc. pp., selbst wenn sie nur "temporär" sehr kurz sind.


----------



## irgendjemand (11. Jan 2012)

> Methoden müssen selten länger als 1-3 Zeilen sein



absoluter schwachsinn ... damit kannst du nicht wirklich was vernünftiges programmieren ...
wenn ich dieser aussage folge würde würde mein code so aussehen


```
methode1()
{
	methode2()
	methode3();
}
methode2()
{
	methode4();
}
methode3()
{
	methode5();
	methode6();
}
methode4()
{
	//..
}
methode5()
{
	//..
}
methode6()
{
	//..
}
```

und du willst mir nicht wirklich verraten nur um dann den eigentlichen code in 1-zeilern *methode 4-6* zu halten einfacher und übersichtlicher sein soll obwohl man diesen dierekt als 5-zeiler schreiben könnte


```
methode()
{
	//..
	//..
	//..
}
```

wirklich ... such dir bessere vorbilder ... mit der aussage im noob-forum ... das tut wirklich weh


----------



## maki (11. Jan 2012)

Weh tut nur deine Ignoranz und Unfähigkeit deine Meinung auszudrücken ohne beleidigend zu werden.

Jeder der das wirkliich mal gemacht hat wird feststellen, dass der Code daurch kürzer wird und einfacher zu strukturieren ist, vor allem in OOP Sprachen.


----------



## irgendjemand (11. Jan 2012)

ach komm ... geh heulen ...

komisch nur das ich nicht der einzige bin der findet das deine aussage hier schwachsinn ist ... von daher ... who cares ...

aber erlich : zeig mir auch nur EIN sinnvolles beispiel was einfacher wird wenn mans deiner meinung nach so affig aufteilt anstatt alles in einer methode zu schreiben *und ich rede jetzt hier mal bewusst von sowas

J7u2 java.net.URLDecoder.decode(String, String)

viel spass beim umsetzen deiner aussage ...


```
public static String decode(String s, String enc)
        throws UnsupportedEncodingException{

        boolean needToChange = false;
        int numChars = s.length();
        StringBuffer sb = new StringBuffer(numChars > 500 ? numChars / 2 : numChars);
        int i = 0;

        if (enc.length() == 0) {
            throw new UnsupportedEncodingException ("URLDecoder: empty string enc parameter");
        }

        char c;
        byte[] bytes = null;
        while (i < numChars) {
            c = s.charAt(i);
            switch (c) {
            case '+':
                sb.append(' ');
                i++;
                needToChange = true;
                break;
            case '%':
		try {

                    
                    if (bytes == null)
                        bytes = new byte[(numChars-i)/3];
                    int pos = 0;

                    while ( ((i+2) < numChars) &&
                            (c=='%')) {
                        int v = Integer.parseInt(s.substring(i+1,i+3),16);
                        if (v < 0)
                            throw new IllegalArgumentException("URLDecoder: Illegal hex characters in escape (%) pattern - negative value");
                        bytes[pos++] = (byte) v;
                        i+= 3;
                        if (i < numChars)
                            c = s.charAt(i);
                    }

                    if ((i < numChars) && (c=='%'))
                        throw new IllegalArgumentException(
                         "URLDecoder: Incomplete trailing escape (%) pattern");

                    sb.append(new String(bytes, 0, pos, enc));
                } catch (NumberFormatException e) {
                    throw new IllegalArgumentException(
                    "URLDecoder: Illegal hex characters in escape (%) pattern - "
                    + e.getMessage());
                }
                needToChange = true;
                break;
            default:
                sb.append(c);
                i++;
                break;
            }
        }

        return (needToChange? sb.toString() : s);
    }
```

ps : wenn du jetzt mit ner antwort kommst von wegen ne is nich und ich soll nich flamen ... würde MIR nur zeigen das du deinen ach so tollen satz nicht mal selbst ernst nimmst ...
viel spass beim umsetzen .. freu mich schon aufs ergebnis


----------



## Gast2 (11. Jan 2012)

Lies dir mal das oben genannte Buch durch, da findest du einige Beispiele


----------



## irgendjemand (11. Jan 2012)

hmm ... wenn ich solche aussagen schon höre das man methode so krass runterbrechen sollte *was alleine bei loops und switch-case schon schwer wird* muss ich mir solchen mist nicht wirklich reinziehen ...

ich meine ... hallo ? gehts noch ? methoden nich länger als 3 zeilen ... aber dafür ein riesiger call-stack ... ähm ... jo ...
ich wollte eigentlich keinen 200 zeilen stack wenns bei nem fehler auch mit nem 10 zeilen stack reicht und ich mich da wohl deutlich einfacher durchfinde ...


----------



## Gast2 (11. Jan 2012)

Niemand schreibt dass es ne Todsünde ist wenn die Methode 4 Zeilen hat. Aber gerade dein Beispiel da oben kann man sehr wohl noch (sinnnvoll) runterbrechen. 

Gerade bei switch statements oder Schleifen kann man den Schleifenrumpf oder die cases eigentlich immer sehr gut in ne Methode auslagern die dann auch nen treffenden Namen hat.


----------



## bygones (11. Jan 2012)

wie kann man sich nur an einer aussage von "1-3 Zeilen" so aufhaengen... wie schon gesagt, wer denn Sinn dahinter nicht versteht sollte nochmal Landeis aussage lesen.

Aber dein bsp ist find ich gut

```
while ( ((i+2) < numChars) &&
                            (c=='%')) {
                        int v = Integer.parseInt(s.substring(i+1,i+3),16);
                        if (v < 0)
                            throw new IllegalArgumentException("URLDecoder: Illegal hex characters in escape (%) pattern - negative value");
                        bytes[pos++] = (byte) v;
                        i+= 3;
                        if (i < numChars)
                            c = s.charAt(i);
                    }
```
ich habe keine Ahnung was da passiert, ich finde die Implementierung unverstaendlich und auf den ersten Blick in keiner weise hilfreich. Wuerde ich so bei einem internen Codereview nicht durchgehen lassen.

wenn man diesen Block in eine Methode auslagern wuerde, die einen entsprechenden Namen hat, so ist sofort auf dem ersten Blick verstaendlich was da passiert. Wenn es dann interessiert kann sich die Methode dann anschauen und auf Verstaendnis "hoffen".

Kurze Methoden haben ebenso den Vorteil dass man eine bessere Teststruktur haben kann, die wesentlich robuster ist und aussagekraeftiger.

Und existierende Beispiele gegen die Clean Code These zu nehmen ist genauso unsinnig. Nur weil es viele falsch machen sollte man es ihnen nicht nachmachen.

Aber ich habe das Gefuehl dass solche Argumente nicht beachtet werden und man weiterhin auf den Zahlen 1-3 rumhaemmert.....

ansonsten denke ich sind diejenigen froh die das hier vertreten, dass die anderen nicht in ihren Teams sind. Ich bin zum Teil in der gluecklichen Lage mitzubestimmen, ob solche bei uns hier ueberhaupt einen Platz finden ;-)


----------



## maki (11. Jan 2012)

@irgendjemand/therealspikee
Soll ich dir jetzt Nachhilfe in refactoring geben oder eher einen Benimmkurs? 

Anhand deiner jetzigen und früheren Aussagen ist eigentlich schon klar dass du ausser Trollen nicht wirklich viel draufhast.. *gähn*

In der Zwischenzeit kannst du dir ja mal die Bedeutung des Wortes "müssen" überlegen.


----------



## irgendjemand (11. Jan 2012)

nur mal so als info : das ist aus dem src.zip vom 7u2 x64 genommen ...
womit wir uns auch gleich wieder unseren allseits geliebten conventions zuwenden könnten welche wie man sieht von Sun/Oracle selbst total ignoriert werden ...

das du da auf den ersten blick nichts rauslesen kannst verwundert mich eigentlich da es schon beim "URLDecoder" hätte klick machen sollen und man wissen sollte das es hier um die umwandlung von hex-darstellungen in byte-werte geht ...

gerade wenn man sich selbst mal einen byte-to-hex / hex-to-byte helper geschrieben hat erkennt man doch recht schnell was hier abgeht ...

und erlich : ob ich jetzt im switch-case die einzelnen case-statements in einzelne methoden aufbreche mit parametern und return-werten die ich dann noch irgendwie weiterverarbeiten muss ...

nah ... mal ganz dumm nur stumpf die zeilen zahl betrachtet wird der code dadurch sogar noch länger *nämlich jedes mal um mindestens 2 zeilen *signatur und closing *bei halbwegs vernünftiger formatierung** ....

und gerade das wort "übersichtlicher" sollte dann negiert werden ... da es nicht gerade übersichtlich ist *und meiner meinung nach nichts mit clean-code zu tun hat* wenn man eine methode nur mit weiteren calls vollstopft anstatt darin mal was zu machen ... aber k ...


----------



## maki (11. Jan 2012)

Hör endlich auf zu heulen und lies mal ein gutes Buch, ist ja nervig...


----------



## irgendjemand (11. Jan 2012)

ahc wie ich euch liebe ... heult hier einen drauf rum von wegen man möge sich ein gutes buch zu legen anstatt seine eigenen prinzipien einfach mal selbst umzusetzen und jemanden der der eigenen ansicht nach davon nichts versteht ein beispiel zu liefern ...


wie gesagt : who cares about nothing ...

da du ja nicht mal bereit bist deine meinung selbst umzusetzen und mir mal ein deiner ansicht nach ordentliches beispiel postest *an hand dessen was ich dir als vorlage gegeben habe* und mich stattdesen auf bücher verweist *die du mir dann auch gerne bezahlen kannst wenn es dich so stresst* frage ich mich wirklich : wer trollt wen und wer hat länger spass daran ?


----------



## Gast2 (11. Jan 2012)

> nur mal so als info : das ist aus dem src.zip vom 7u2 x64 genommen ...
> womit wir uns auch gleich wieder unseren allseits geliebten conventions zuwenden könnten welche wie man sieht von Sun/Oracle selbst total ignoriert werden ...


Wurd doch oben schon erwähnt, nur weils viele machen muss das noch lange nicht richtig sein... Außerdem gibts noch ne ganze Menge mehr, dass in der Java API nicht besonders schön gelöst wurde 



> das du da auf den ersten blick nichts rauslesen kannst verwundert mich eigentlich da es schon beim "URLDecoder" hätte klick machen sollen und man wissen sollte das es hier um die umwandlung von hex-darstellungen in byte-werte geht ...
> 
> gerade wenn man sich selbst mal einen byte-to-hex / hex-to-byte helper geschrieben hat erkennt man doch recht schnell was hier abgeht ...


Und die anderen sollen dumm sterben? 
Wär doch nett wenn jeder direkt auf anhieb erkennt was da gemacht wird. Zum Beispiel... durch nen treffenden Methodennamen!



> und erlich : ob ich jetzt im switch-case die einzelnen case-statements in einzelne methoden aufbreche mit parametern und return-werten die ich dann noch irgendwie weiterverarbeiten muss ...


Aber dann weiß der Leser wenigstens was da gemacht wurde, er schaut sich einfach den Methodennamen an und sieht "aha, hier wurd grad ne byte-to-hex konvertierung gemacht."



> nah ... mal ganz dumm nur stumpf die zeilen zahl betrachtet wird der code dadurch sogar noch länger *nämlich jedes mal um mindestens 2 zeilen *signatur und closing *bei halbwegs vernünftiger formatierung** ....
> 
> und gerade das wort "übersichtlicher" sollte dann negiert werden ... da es nicht gerade übersichtlich ist *und meiner meinung nach nichts mit clean-code zu tun hat* wenn man eine methode nur mit weiteren calls vollstopft anstatt darin mal was zu machen ... aber k ...


Der Code mag vielleicht etwas länger werden (was nicht unbedingt sein muss), er wird aber deutlich übersichtlicher. Idealerweise ließt du den dann später wie nen gutes Buch


----------



## maki (11. Jan 2012)

> ahc wie ich euch liebe


Offensichtlich, denn sonst hast du sicherlich keinen "menschlichen" Kontakt.

Ach, das Internet und seine Spinner... aber jedes Dorf braucht einen Dorftrottel und jedes Forum seinen Troll, also entspann dich und geniesse deinen Aufenthalt, dank dir hab ich oft genug zu lachen


----------



## Schandro (11. Jan 2012)

@irgendjemand Traurig das du hier nicht registriert bist, sonst könnte ich dich auf meine ignore-Liste setzen.

@TO
Ich persönlich finde es ausnahmslos immer schöner mit { }, aber schlussendlich kommt es nur darauf an das man sich für ein Format entscheidet und das konsequent durchzieht. Und bei Teamprojekten müssen sich halt alle auf ein Format einigen. 

Viel mehr gibt es zu diesem Thema nicht mehr zu sagen, könnte also geschlossen werden bevor hier noch weiter getrollt wird.


----------



## codechaos (11. Jan 2012)

Mal kurz die Argumente beider Seiten zusammengefasst, die ich noch im Kopf habe, damit sich das ganze vielleicht in eine sachlichere Diskussion entwickelt.

*Kurze Methoden*:
+ Teststruktur
+ besseres Verständnis der Abläufe (Lesbarkeit) => schnelleres Einarbeiten in fremden Code
(+ eventuelle Wiederverwendbarkeit einzelner Methoden)
o Insgesamt längerer Code
- langer Callstack
- Rückgabewerte müssen entsprechend verarbeitet werden

*Lange Methoden*:
+ Kapselung komplette Funktionalität
- komplexe Abläufe sind nicht direkt verständlich => höhere Einarbeitungszeit


Ich bitte um jeweilige Erweiterungen


----------



## maki (11. Jan 2012)

> o Insgesamt längerer Code
> - langer Callstack
> - Rückgabewerte müssen entsprechend verarbeitet werden


Das ist falsch.


----------



## bygones (11. Jan 2012)

codechaos hat gesagt.:


> - langer Callstack


oeh wie? warum?


codechaos hat gesagt.:


> - Rückgabewerte müssen entsprechend verarbeitet werden


oeh wenns in einem Block steht muss es auch verarbeitet werden... es ist kein unterschied



codechaos hat gesagt.:


> *Lange Methoden*:
> + Kapselung komplette Funktionalität


genau eben nicht, durch lange Methoden verliert man eine richtige Kapselung


codechaos hat gesagt.:


> - komplexe Abläufe sind nicht direkt verständlich => höhere Einarbeitungszeit


die Einarbeitungszeit ist das geringere Problem, die Wartungszeit und die Moeglichkeit code zu aendern ist das Problem


----------



## codechaos (11. Jan 2012)

Ich habe wirklich nur kurz gesammelt, was die Leute hier geschrieben haben. Und möchte kurz noch betonen, dass das teilweise nicht meiner Meinung entspricht 



maki hat gesagt.:


> Das ist falsch.


Es wäre schön, wenn du dazu etwas mehr sagen könntest! Leider habe ich Clean Code nicht gelesen, es steht allerdings recht weit oben auf meiner Einkaufsliste. 



			
				bygones hat gesagt.:
			
		

> genau eben nicht, durch lange Methoden verliert man eine richtige Kapselung


Hier habe ich mich wohl falsch ausgedrückt, entschuldige bitte! Ich meinte mit dem Punkt, dass die komplette Funktionalität in einer Methode zu finden ist. Ich hoffe, ich habe damit die Meinung der Contra-Kurze-Methoden Partei besser wiedergegeben.



			
				bygones hat gesagt.:
			
		

> oeh wenns in einem Block steht muss es auch verarbeitet werden... es ist kein unterschied


Aber wie würde es zum Beispiel aussehen, wenn innerhalb eines Codeblockes verschiedene Variablen einen neuen Wert zugewiesen bekommen, die allerdings beide Abhängig voneinander sind, weil es innerhalb einer Schleife o.ä. geschieht.


----------



## Sonecc (11. Jan 2012)

maki hat gesagt.:


> Das ist falsch.



Sorry maki, aber diese Aussage ist so gehaltvoll wie ein Stein.
Du selbst würdest über solche Kommentare, die ohne jegliche Begründung irgendwelche Aussagen tätigen, meckern und ggf. als nutzlos markieren und ignorieren. Sei doch bitte so professionell und erkläre demjenigen, warum es denn falsch sein soll...
Finde es schade, dass der ein oder andere hier, der ja wirklich was drauf hat und einiges an Erfahrung bieten kann, gerade in diesem Thema jegliche Professionalität vermissen lässt und das Thema damit eigentlich nur unnötig provokativ gestaltet (btw. damit war nicht der gast gemeint)

Darunter zählt übrigens auch das wiederholte runterbeten des Satzes ("eine Methode darf nie mehr als 5 Zeilen haben"). Dass diese Aussage kurz darauf relativiert werden musste, zeigt wie übertrieben sie war, auch wenn damit das richtige ausgedrückt werden sollte.


----------



## Gast2 (11. Jan 2012)

irgendjemand hat gesagt.:


> nur mal so als info : das ist aus dem src.zip vom 7u2 x64 genommen ...
> womit wir uns auch gleich wieder unseren allseits geliebten conventions zuwenden könnten welche wie man sieht von Sun/Oracle selbst total ignoriert werden ...



Gute wenn einer aus dem 7u2 Entwickler von der Brücke springt, springst du bitte hinter her =)


----------



## tfa (11. Jan 2012)

> - langer Callstack


Sicherlich wird der Callstack länger, aber warum sollte das ein Problem sein? Warum also das [c]-[/c]?
Der Einsatz von komplexeren Frameworks oder einfache Rekursion vergrößert auch  den Callstack, und da stört's doch niemanden.


----------



## maki (11. Jan 2012)

Sonecc hat gesagt.:


> Sorry maki, aber diese Aussage ist so gehaltvoll wie ein Stein.
> Du selbst würdest über solche Kommentare, die ohne jegliche Begründung irgendwelche Aussagen tätigen, meckern und ggf. als nutzlos markieren und ignorieren. Sei doch bitte so professionell und erkläre demjenigen, warum es denn falsch sein soll...
> Finde es schade, dass der ein oder andere hier, der ja wirklich was drauf hat und einiges an Erfahrung bieten kann, gerade in diesem Thema jegliche Professionalität vermissen lässt und das Thema damit eigentlich nur unnötig provokativ gestaltet (btw. damit war nicht der gast gemeint)
> 
> Darunter zählt übrigens auch das wiederholte runterbeten des Satzes ("eine Methode darf nie mehr als 5 Zeilen haben"). Dass diese Aussage kurz darauf relativiert werden musste, zeigt wie übertrieben sie war, auch wenn damit das richtige ausgedrückt werden sollte.


@Sonecc
Was ist denn nun mit dir schon wieder?
Den von dir zitierten Satz habe ich so nicht gesagt  ("eine Methode darf nie mehr als 5 Zeilen haben"), einfach mal nachlesen, halte dich für intelligent und verständig, der Fehler liegt hier auf deiner Seite.
Wann war ich unnötig provokativ?
Wann habe ich meine Aussage relativieren müssen?

Wenn man Leuten hier sowas unterstellt sollte man das schon belegen können, oder es eben zurücknehmen.

Könntest dich auf inhaltliche Diskussionen konzentrieren anstatt mir mal wieder irgendetwas vorzuwerfen...


----------



## bygones (11. Jan 2012)

codechaos hat gesagt.:


> Es wäre schön, wenn du dazu etwas mehr sagen könntest! Leider habe ich Clean Code nicht gelesen, es steht allerdings recht weit oben auf meiner Einkaufsliste.


laengerer code entsteht dadurch, dass man mehr methoden hat, das ist aber gewiss kein Problem und kann nicht als negativ angesehen werden.

Der Callstack ist bei Fehlern relevant und wenn man dort eine bessere Unterteilung seiner Methoden hat ist es einfacher seinen Fehler zu finden bzw mit Tests nachzuweisen, als wenn das bei einer langen Methode der Fall ist. Ansonsten ist der Callstack reichlich irrelevant und somit nicht als Argument heranzuziehen.

Zu den Rueckgabewerten unten



codechaos hat gesagt.:


> Hier habe ich mich wohl falsch ausgedrückt, entschuldige bitte! Ich meinte mit dem Punkt, dass die komplette Funktionalität in einer Methode zu finden ist. Ich hoffe, ich habe damit die Meinung der Contra-Kurze-Methoden Partei besser wiedergegeben.


sie geht nur in einem zeilenlangen biest unter und man verliert schnell eine Uebersicht welche Variablen wie nun wann und wo im Spiel sind. Die Gefahr von unabsichtlichen Variablen aenderns (da auch wenig final meist im spiel ist), ist bei langen Methoden groesser



codechaos hat gesagt.:


> Aber wie würde es zum Beispiel aussehen, wenn innerhalb eines Codeblockes verschiedene Variablen einen neuen Wert zugewiesen bekommen, die allerdings beide Abhängig voneinander sind, weil es innerhalb einer Schleife o.ä. geschieht.


das ist leider zu situationsabhaenig. Wenns lokale Variablen sind ist es ziemlich egal. Wenn es Instanzvariablen sind ebenso. Generell ist es meist eher ein Zeichen dafuer, dass eben diese Methode zu viel macht bzw Wissen zu sehr verteilt ist, so dass zu viele Abhaengigkeiten bzw Seiteneffekte entstehen. 

Es ist klar dass hier generelle Antworten erwartet werden, was aber nicht immer moeglich ist. Ich bin gern bereit bei entsprechenden Ton (!) einige Beispiele zu bearbeiten, so wie es nach meinem Verstaendnis besser ist. 

Weiterhin sollte es aber auch klar sein, dass keiner hier anfaengt bekannte Literatur abzuschreiben, nur weil jemand anderes nicht das entsprechende Buch gerade kennt. Diese Informationen kann man sich selbst beschaffen und dank dieses Ding namens Internet auch sehr leicht bekommen (google nach clean code, Misko hevery, Uncle Bob etc bringt einiges).


----------



## bygones (11. Jan 2012)

Sonecc hat gesagt.:


> Darunter zählt übrigens auch das wiederholte runterbeten des Satzes ("eine Methode darf nie mehr als 5 Zeilen haben"). Dass diese Aussage kurz darauf relativiert werden musste, zeigt wie übertrieben sie war, auch wenn damit das richtige ausgedrückt werden sollte.


bevor du ausholst, lies es nochmal in ruhe... die Aussage "darf nie mehr als 5 zeilen haben" ist nie gefallen

ah maki schon geschrieben


----------



## Sonecc (11. Jan 2012)

Der Satz war mit Absicht in Anführungszeichen. Genaugenommen hast du gesagt:



> Methoden müssen selten länger als 1-3 Zeilen sein...



Nicht wirklich besser als meine sinngemäße Aussage, die ich aus dem Kopf zusammengezimmert hab.

Die relativierung war eher eine Einschränkung und weitergehende Erläuterung die deine Aussage erklärt, da sie für sich eben recht übertrieben wirkt. (Da muss ich mich entschuldigen, falsche Wortwahl)
Die aussage 1-3 Zeilen halte ich dabei für übertrieben, etwas mehr zeilen dürften den Durchschnitt darstellen der sinnvoll ist.
Das ganze klingt dann für einfach gestrickte Menschen nunmal provokativ, was man am Gast ja deutlich merken kann.



			
				Landei hat gesagt.:
			
		

> Eine feste Zeilenzahl ist ja nicht vorgegeben, die Frage ist immer, ob sich die Methode sinnvoll unterteilen lässt. Es gibt sicher Methoden mit zwanzig Zeilen, wo nichts aufzuteilen oder zu vereinfachen geht (etwa weil bestimmte Daten an einem vorgegebenen Objekt gesetzt werden müssen), und Methoden mit acht Zeilen, die unbedingt aufgebrochen werden müssen.





			
				bygones hat gesagt.:
			
		

> es ist eine Zeile.... es geht um den Inhalt einer Methode. Und wenn man auf der Zahl 3 an sich nun rumdonnert hat man den Sinn der Aussage makis nicht verstanden




Provokativ wurdest du übrigens recht schnell, als sich der Gast geäußert hat. Ich denke da brauche ich nichts zu zitieren, das weißt du wohl selbst.


Und zu guter Letzt nochmal: Ich habe mich da eingeklinkt wegen deinem Einzeiler. Eine solche Aussage ist schlicht unnötig, da sie keinen Gehalt besitzt, nichts erläutert und schlicht und einfach nur hart und in dem Zusammenhang sogar eben teilweise provokativ sein kann.

Wüsste auch nicht, dass ich dir dauernd was vorwerfen würde.
Hatte mal meine Probleme mit Slater aber bei dir bisher noch nicht.
Du solltest das daher auch nicht als Angriff verstehen sondern eher als halbwegs konstruktive Kritik. Wenns wie ein Angriff rüberkam, tut es mir leid, das sollte es nicht.



Btw. bygones vertritt den gleichen Standpunkt und liefert dich gleichen argumente, ist dabei aber nie provokativ gewesen.


----------



## Andi_CH (11. Jan 2012)

irgendjemand hat gesagt.:


> hmm ... wenn ich solche aussagen schon höre das man methode so krass runterbrechen sollte *was alleine bei loops und switch-case schon schwer wird* muss ich mir solchen mist nicht wirklich reinziehen ...
> 
> ich meine ... hallo ? gehts noch ? methoden nich länger als 3 zeilen ... aber dafür ein riesiger call-stack ... ähm ... jo ...
> ich wollte eigentlich keinen 200 zeilen stack wenns bei nem fehler auch mit nem 10 zeilen stack reicht und ich mich da wohl deutlich einfacher durchfinde ...



Ich steh wenigstes zu meinem Nick, auch wenn dadurch mein Ruf als "Unfähigster Programmierer des Universums" gefestigt wird. (Womit ich ganz klar festhalten will, dass diese Äusserung nicht von mir kam, auch wenn ich im Grossen Ganzen (fachlich! nicht den Tonfall betreffend) derselben Meinung bin.)

Bücher und Guidelines zielen einfach an der Realität vorbei - was gestern in den Himmel gelobt wurde (Singleton, Serialisierung als Persistierung, etc. etc.) ist wenig später weniger bis gar nichts mehr wert ....

Also: Argumente zählen VIEL mehr als ein Verweis auf irgend ein Buch.

Aber zurück zum Verkürzen des Codes: Ich habe nette Einzeiler entdeckt, die ich gelten lassen kann.


```
public void setWert(int pWert) { mWert = pWert; }
public int getWert() { return mWert; }
```

umgeschrieben in die [triefende Ironie]gesetzlich vorgeschriebene[/triefende Ironie] Version ist es schon weniger elegant aber immer noch tolerierbar:


```
public void setWert(int wert) { this.wert = wert; }
public int getWert() { return wert; }
```


----------



## Gast2 (11. Jan 2012)

Wenn du das noch umschreibst in:

```
public void setWert(int pWert) { mWert = pWert; } public int getWert() { return mWert; }
```
sparst du dir noch ne ganze Zeile :joke:

Ne aber mal im Ernst, warum sollte man sich für die paar getter/setter die man hat die paar Zeilen sparen. Wenn du allerdings 20 30 getter/setter hast, dann liegt das Problem woanders


----------



## Gast2 (11. Jan 2012)

Andi_CH hat gesagt.:


> Also: Argumente zählen VIEL mehr als ein Verweis auf irgend ein Buch.



Also Clean Code sollte eigentlich jeder Java Programmierer mal gelesen haben und diese "Weisheiten" bestehen schon länger und zusätzlich zu diesem Buch wurden ja einige Argumente angebracht.
Aber wenn man Beratungsresistenz (nicht dich bezogen) ist und keine andere Meinung gelten darf, kann man auch nichts machen  =).


----------



## bygones (11. Jan 2012)

Andi_CH hat gesagt.:


> Ich steh wenigstes zu meinem Nick, auch wenn dadurch mein Ruf als "Unfähigster Programmierer des Universums" gefestigt wird. (Womit ich ganz klar festhalten will, dass diese Äusserung nicht von mir kam, auch wenn ich im Grossen Ganzen (fachlich! nicht den Tonfall betreffend) derselben Meinung bin.)


da musste ich lachen  einfach gut geschrieben



Andi_CH hat gesagt.:


> Bücher und Guidelines zielen einfach an der Realität vorbei - was gestern in den Himmel gelobt wurde (Singleton, Serialisierung als Persistierung, etc. etc.) ist wenig später weniger bis gar nichts mehr wert ....
> 
> Also: Argumente zählen VIEL mehr als ein Verweis auf irgend ein Buch.


nur weil etwas moeglicherweise in ein paar Jahren nicht mehr gueltig ist, heisst das nicht, dass man sich deswegen wie ein Anarchist auffuehren muss. Ausserdem unterliegen Argumente genauso einem Verfallsdatum wie Buecher


----------



## codechaos (11. Jan 2012)

Die Sache mit dem langen Code habe ich auch auch eher als neutralen Punkt gesehen, hielt es der Vollständigkeit halber dennoch für erwähnenswert.
Meine Meinung zum langen Callstack ist ebenfalls, dass dies kein starkes (wenn überhaupt gültiges) Argument ist, warum das so ist, wurde bereits genannt.

Zu der Sache mit der Verarbeitung der Rückgabewerte kam mir als erstes so etwas in den Sinn:

```
// ...
Object a, b, c;
List<Object> objectList = new ArrayList<Object>();
fillList(objectList);
for(Object o : objectList) {
	if(isValidA(o)) {
		a = o;
	}else if(isValidB(o)) {
		b = o;
	}else if(isValidC(o)) {
		c = o;
	}
}
// mit a, b, c weiterarbeiten
```
Es sollen hier aus der Liste ein paar Elemente raus gesucht werden, die bestimmte Eigenschaften erfüllen und anschließend werden die weiterverwendet. Ob man dies mit anderen Mitteln einfacher lösen kann, lassen wir bitte einfach ausser Acht, da es hier um einen anderen Punkt geht 

Um die Funktionalität aus dieser Methode auszulagern, sehe ich erst mal zwei Möglichkeiten: 
drei Methoden, die mir jeweils das Element für a, b oder c liefern
Eine Methode, die mir ein Array von Elementen zurück gibt
Bei Variante 1 wird die Liste drei mal durchlaufen, was sich laufzeittechnisch schon nicht richtig anhört.
Variante 2 müsste folgendermaßen weiterverarbeitet werden:

```
// ...
Object a, b, c;
List<Object> objectList = new ArrayList<Object>();
fillList(objectList);

final Object[] filteredElements = filterList(objectList);
a = filteredElements[0];
b = filteredElements[1];
c = filteredElements[2];
//mit a, b, c weiterarbeiten
```

Wäre dies die optimale Lösung? Meine Praxiserfahrung ist zwar noch sehr begrenzt und daher weiß ich nicht, wie ich es beschreiben soll, aber auch diese Lösung "fühlt" sich nicht wirklich "richtig" an (bitte verzeiht die Ausdrucksweise, ich weiß ich nicht, wie ich es besser beschreiben soll). In einem Array werden für mich recht "ähnliche" Dinge gespeichert, aber hier werden gefilterte Elemente mit ganz speziellen Eigenschaften zusammen gefasst.


----------



## Andi_CH (11. Jan 2012)

Es sind noch viel mehr (~200) - das ist ein Datenhaltungsmoloch der zu 90% aus Variablendeklarationen, gettern und settern besteht und dessen Objekte im ganzen System herumgereicht werden. Keine Struktur nichts.

Einige wenige getter machen einfache Berechnungen oder Zusammenstellungen von Daten, einige setter haben mehr als einen Parameter.
Kommentaranteil (was welche Variable im Gesamtsystem für eine Bedeutung hat) ist <5%

Also - das Problem liegt an gaaaaanz andere Stellen als an einzeiligen Prozedürchen.
Nein, das Ding ist nicht von mir. Und Nein, ich finde es nicht gut 

Das ist ein ähnliches Niveau wie ein Statement dass ich irgendwo gefunden habe

(Na ja, ein klein wenig komplizierter war schon codiert, aber das ändert nichts an der Sache.)


```
if (wert < minimum)
   return false;
else
   return true;
```

Leute, es hebt mein Ego ungemein wenn ich solchte Statements finde - ich fühl mich dann richtig gut


----------



## Andi_CH (11. Jan 2012)

SirWayne hat gesagt.:


> Aber wenn man Beratungsresistenz (nicht dich bezogen) ist und keine andere Meinung gelten darf, kann man auch nichts machen  =).



Mich hat geprägt, dass ich seit über 15 Jahren immer nach projektspezifischen und sprachunabhängigen Guidelines gearbeitet habe / arbeiten musste / na ja manchmal auch durfte.

Bis ich mich nur schon daran gewöhnt haben, dass { auf derselben Zeile wie z.B. is stehen darf und } nicht genau darunter sein MUSS 

Aber wer sich nur noch um die Detailformattierung des Codes kümmern muss, hat ein recht entspanntest Leben ;-)

Wer keine Argumente anführt welche den Sinn seiner Aussagen untermauern vertritt IMO einen Stand- oder Gesichtspunkt


----------



## Gast2 (11. Jan 2012)

Andi_CH hat gesagt.:


> Bis ich mich nur schon daran gewöhnt haben, dass { auf derselben Zeile wie z.B. is stehen darf und } nicht genau darunter sein MUSS



Stimmt =)... Aber für solche Sachen gibt es auch Codeformatter z.B. für Eclipse, dann haben alle Entwickler die gleiche Formatierung.


----------



## bygones (11. Jan 2012)

```
// ...
Object a, b, c;
List<Object> objectList = new ArrayList<Object>();
fillList(objectList);
for(Object o : objectList) {
    if(isValidA(o)) {
        a = o;
    }else if(isValidB(o)) {
        b = o;
    }else if(isValidC(o)) {
        c = o;
    }
}
```
ein etwas unglueckliches bsp. So erstmal wirkt es nach design fehler an sich. Umstrukturierung und aenderung ist meist nur mit etwas Kontextwissen moeglich. Die Frage hier ist was passieriert mit a,b,c - ist es sinnvoll eine Zuweisung mehrfach zu ueberschreiben etc. Ich tu mir schwer bei einem solch fiktiven Bsp sinnvolle Antworten zu finden...


----------



## Firephoenix (11. Jan 2012)

genauso geht es mir auch bei dem decode-Beispiel von dem anonymen user 
Persönlich würde ich sagen "super Gegenbeispiel für schönen Code in einem Framework"

Ohne Kontextwissen ist das Ding mit Sicherheit nicht wartbar, vor allen dingen nicht für jemanden der sich einarbeiten muss.

Und gerade das ist ja auch eins der Hauptthemen von Clean Code (und nein alles davon sehe ich auch nicht in Stein gemeißelt - trotzdem keine schlechte Lektüre) - man schreibt den Code auch für andere - und sollte ihn daher so Strukturieren, dass jemand anderes vergleichsweise schnell die Struktur des Codes erfassen kann, schnell sieht was welche Variable wo tut etc.
Vielleicht kann man das Ding nicht besser schreiben, oder es gibt hier bestimmte Gründe warum die Methode in der Form so da auftaucht - aber wie bygones schon zu dem Code gesagt hat:


> Wuerde ich so bei einem internen Codereview nicht durchgehen lassen.


Das sehe ich genauso, wenigstens soviel erkennt man nämlich:
Die Methode macht wesentlich mehr als nur eine kleine Aufgabe, entsprechende Teile lassen sich sicher benennen und auslagern (*warte auf "wäää mein Stack ist so lang"-Geflame*).
Das soll jetzt aber nicht in ein Refactoring von der Methode ausarten, ich finde sie ist nur ein recht passendes Beispiel gegen fast jeden Grundsatz der in Clean Code bzw generell von einigen Leuten hier vertreten wird 
Gruß


----------



## darekkay (12. Jan 2012)

Andi_CH hat gesagt.:


> obwohl das Ctrl-A , Ctrl-I (automatisches Einrücken) längst zum Reflex geworden ist und das Finden von solchen Fehlern massiv vereinfacht.



Ich empfehle dir eine automatische Formatierung beim Speichern einer Datei einzustellen - dadurch sparst du dir diesen Griff, denn ich früher auch sehr oft benutzt habe


----------



## codechaos (12. Jan 2012)

bygones hat gesagt.:


> ```
> // ...
> Object a, b, c;
> List<Object> objectList = new ArrayList<Object>();
> ...


Es ist wirklich ein eher unglückliches Beispiel, gerade weil man nicht weiß, was nachher passieren soll. Mittlerweile denke ich eher, dass es bei so einem Fall eventuell sinnvoller wäre, nicht nur das Filtern, sondern auch die entsprechenden weiteren Arbeitsschritte auszulagern. Sodass es eher eine filterAndDoSomething-Methode ist, die dort aufgerufen wird.

Wie es scheint, ist die Kontra-kurze-methoden-Partei nicht mehr vertreten bzw. übergewandert


----------



## knoppers (12. Jan 2012)

darekkay hat gesagt.:


> Ich empfehle dir eine automatische Formatierung beim Speichern einer Datei einzustellen - dadurch sparst du dir diesen Griff, denn ich früher auch sehr oft benutzt habe



Dies habe ich auch ganz gerne gemacht, bzw. mache ich heute auch noch. Problem ist hier wenn man schon ältere bestehende Projekte bearbeitet und diese dann über Subversion Merged. Hier hat Subversion dann manchmal ein Problem da bei einem Speichervorgang eine ganze Quelldatei formatiert wird. Die Quelldatei vielleicht +- 1000 Code Zeilen hat und vorher noch nie formatiert wurde. Desweiteren hat man hier ein Problem bei prüfen der Historie, da man nicht sofort erkennt wo genau die Änderung geschah.
Nicht desto trotz ist dies eine sehr gute Möglichkeit.


----------



## Spacerat (12. Jan 2012)

Lange Methoden mal hin oder her... (Dieser Disput ist wahrhaft lächerlich) mal BTT...
Ging es dem TS nicht irgendwann mal darum, ob diese Klammern besserer Codestyle ist oder nicht. Ich sage mal: "*Ja, auf jeden Fall!*" und zwar aus folgendem Grund: *Dangling (hängendes) else*. Ich selbst kenne es nur noch vom "Hören - Sagen" und müsste selbst auch danach Googeln, da ich halt diese Klammern verwende.
	
	
	
	





```
if(anything)
  doSomething();
  if(anythingElse)
    doSomethingElse();
else
  doOtherStupidThings();
```
Kann hier noch irgendjemand genau sagen, zu welchem [c]if[/c] das [c]else[/c] gehört? Stellt euch mal vor, das 2. [c]if[/c] wurde nachträglich eingefügt. OMG
@TS: Tu dir einen grossen Gefallen und verwende diese Klammern... immer! Denn man vergisst auch trotz automatischer Einrückung gerne mal zu welchem [c]if[/c] das [c]else[/c] gehört bzw. gehören soll, nur stört es einen bei der Verwendung der Klammern nicht mehr.
[EDIT]Ok... bei Wikipedia wird das Problem ganz ohne Alsheimer beschrieben... Dangling Else[/EDIT]


----------



## knoppers (12. Jan 2012)

Spacerat hat gesagt.:


> Lange Methoden mal hin oder her... (Dieser Disput ist wahrhaft lächerlich) mal BTT...
> Ging es dem TS nicht irgendwann mal darum, ob diese Klammern besserer Codestyle ist oder nicht. Ich sage mal: "*Ja, auf jeden Fall!8/b]" und zwar aus folgendem Grund: Dangling (hängendes) else. Ich selbst kenne es nur noch vom "Hören - Sagen" und müsste selbst auch danach Googeln, da ich halt diese Klammern verwende.
> 
> 
> ...


*

Das else gehört zum zweiten if da man ohne Klammerung maximal ein Statement schreiben kann.
Anders wäre dies hier (ohne doSomething): 



		Java:In die Zwischenablage kopieren


if(anything)
  if(anythingElse)
    doSomethingElse();
else
  doOtherStupidThings();


hier würde das else zum zweiten if gehören. Probier es in Eclipse aus und formatiere den Code.*


----------



## darekkay (12. Jan 2012)

Spacerat hat gesagt.:


> Kann hier noch irgendjemand genau sagen, zu welchem [c]if[/c] das [c]else[/c] gehört?



Natürlich, da eine bereits besprochene automatische Einrückung sowas niemals zulassen würde. Das zweite if wäre auf der selben Ebene, wie das erste if und das else. Außedem würde _ich_ Nach doSomething() eine Leerzeile lassen, da die beiden Sachen voneinander unabhängig sind (das anything und anythingElse könnten suggerieren, dass dem nicht so ist (schließlich ist es nicht else if)).


```
if(anything)
  doSomething();

if(anythingElse)
    doSomethingElse();
else
  doOtherStupidThings();
```

Ich mag Klammern bei sehr einfachen if-Anweisungen auch nicht. Allerdings ist es ja auch oft so, dass man der if-Anweisung etwas hinzufügen möchte, sei es eine sysout-Anweisung um zu schauen, ob das Programm wirklich die if-Anweisung erreicht. Schreibt man immer die Klammern mit, so reicht ja eine neue Zeile. So muss noch selbstständig { und } eingefügt werden. Aufwand sicherlich nicht sooo hoch, aber auf Dauer könnte es auch stören.


----------



## knoppers (12. Jan 2012)

knoppers hat gesagt.:


> Das else gehört zum zweiten if da man ohne Klammerung maximal ein Statement schreiben kann.
> Anders wäre dies hier (ohne doSomething):
> 
> 
> ...



lustig wird es dann wenn es so wird

```
if (test())
if (testa())
a = "x";
else
a = "y";
else
a = "z";
```


----------



## darekkay (12. Jan 2012)

Bei nur einem else besteht noch die Gefahr, dass man aus Versehen ein Semikolon hinter die erste if-Anweisung macht, dann ist auch alles fürn Popo ^^

So oder so: die Klammern verbessern auf jeden Fall die Lesbarkeit und beugen Tippfehlern vor. Allerdings werde ich einzeilige, unverschachtelte if-Anweisungen immernoch ohne Klammern schreiben, da man bei

```
if(muh == null)
   return;

...
```
nun wirklich nichts missverstehen kann.


----------



## Gast2 (12. Jan 2012)

darekkay hat gesagt.:


> Bei nur einem else besteht noch die Gefahr, dass man aus Versehen ein Semikolon hinter die erste if-Anweisung macht, dann ist auch alles fürn Popo ^^
> 
> So oder so: die Klammern verbessern auf jeden Fall die Lesbarkeit und beugen Tippfehlern vor. Allerdings werde ich einzeilige, unverschachtelte if-Anweisungen immernoch ohne Klammern schreiben, da man bei
> 
> ...



Wie gesagt wenn man einen Code Formatter(wie die ifs aussehen, wie schleifen,wie lang die zeilen sind usw.) benutzt hat jeder Entwickler die gleiche Formattierung und man kann keine eigenen Sachen machen, eine gescheite IDE nimmt einen auch sowas ab.


----------

