Programmierstil

[Inuriel]

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]

Code Conventions

Note: if statements always use braces {}. Avoid the following error-prone form:
if (

condition) //AVOID! THIS OMITS THE BRACES {}!


statement;

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

 

[emailundlos]

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

 

[Firephoenix]

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]

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

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]

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

Ich finde es nicht schön

 

[bygones]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

 

[irgendjemand]

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]

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]

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]

@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]

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]

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

 

[irgendjemand]

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]

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]

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]

@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]

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]

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

Das ist falsch.

 

[bygones]

- langer Callstack

oeh wie? warum?

- Rückgabewerte müssen entsprechend verarbeitet werden

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

Lange Methoden:
+ Kapselung komplette Funktionalität

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

- 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]

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

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.

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.

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]

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]

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]

- 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]

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]

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

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

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]

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]

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.

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.

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]

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]

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]

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]

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

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