Re: [ccd] Variablen innerhalb oder ausserhalb einer Schleife?

481 views
Skip to first unread message

Stefan Lieser

unread,
Dec 11, 2012, 9:59:17 AM12/11/12
to clean-code...@googlegroups.com
Hallo Jan,

für mich persönlich ist der Code lesbarer, wenn die Deklaration in der Schleife erfolgt. Die zusätzlichen Zeilen vor der Schliefe empfinde ich als unnötiges Rauschen.

Performance ist für mich absolut kein Argument. Bis es eines ist :-) Das heißt dann aber, dass mittels Profiler o.ä. nachgewiesen ist, dass eine Verlagerung der Deklaration (aus Kundensicht) einen gewichtigen Vorteil hat.

Clean Code Developer Bausteine zu dem Thema:
- Vorsicht vor Optimierung
- Don't Repeat Yourself
- Sourcecode Konventionen


Herzliche Grüße
Stefan Lieser
--


Am 11.12.2012 um 15:43 schrieb Jan Schumacher <jan.schu...@gmail.com>:

Hallo!

Wollte mich mal kurz vorstellen: Ich bin Jan Schumacher, arbeite für ein
Unternehmen in dem wir seit kurzem die Regeln des CCD anwenden und
damit experimentieren. Ich programmiere seit ca. 2 Jahren mit Groovy und
Grails, davor, so gut wie ausschließlig, mit Java.

Es gab heute während einer Code Review eine Diskussion mit einem Mitentwickler bei
der es darum ging ob es schönerer oder schlechterer Code ist Variablen
mit Objekten innerhalb einer Schleife oder ausserhalb einer Schleife zu deklarieren.
In unserem Beispiel werden die Objekte allerdings nur für einen Schleifendurchgang
und beim nächsten wieder überschrieben.

String test1
String test2
(0..20).each{
    test1 = "Hallo Welt " + it
    test1 = "Hallo Welt " + (it * 2)
}

Die Argumente waren, wie vorher zu erwarten, die Performance sei
dadurch besser, der Speicher sei nicht unnötig in Verwendung und es sei besser zu
lesen. Ich habe gegen die Punkte Leserligkeit und Performance widersprochen und bin
nach kurzem suchen auf "Google" auf folgendes dazu gestoßen:

http://weblogs.java.net/blog/ddevore/archive/2006/08/declare_variabl_1.html

Jetzt ist für mich ganz klar die Frage: Was sagt Clean Code dazu? Gibt es dafür
überhaupt Regeln und wenn wie sind sie am besten anzuwenden?

Mit freundlichen Grüßen
Jan Schumacher

--
Sie haben diese Nachricht erhalten, weil Sie der Google Groups-Gruppe Clean Code Developer beigetreten sind.
Besuchen Sie https://groups.google.com/d/msg/clean-code-developer/-/g_yfaB1rEyMJ, um diese Diskussion im Web anzuzeigen.
Wenn Sie Nachrichten in dieser Gruppe posten möchten, senden Sie eine E-Mail an clean-code...@googlegroups.com.
Wenn Sie aus dieser Gruppe austreten möchten, senden Sie eine E-Mail an clean-code-devel...@googlegroups.com.
Besuchen Sie die Gruppe unter http://groups.google.com/group/clean-code-developer?hl=de, um weitere Optionen zu erhalten.

Mario Noack

unread,
Dec 11, 2012, 10:01:15 AM12/11/12
to clean-code...@googlegroups.com
Am 11.12.2012, 15:43 Uhr, schrieb Jan Schumacher
<jan.schu...@gmail.com>:

> Hallo!
>
> Wollte mich mal kurz vorstellen: Ich bin Jan Schumacher, arbeite für ein
> Unternehmen in dem wir seit kurzem die Regeln des CCD anwenden und
> damit experimentieren. Ich programmiere seit ca. 2 Jahren mit Groovy und
> Grails, davor, so gut wie ausschließlig, mit Java.
>
> Es gab heute während einer Code Review eine Diskussion mit einem
> Mitentwickler bei
> der es darum ging ob es schönerer oder schlechterer Code ist Variablen
> mit Objekten innerhalb einer Schleife oder ausserhalb einer Schleife zu
> deklarieren.
> In unserem Beispiel werden die Objekte allerdings nur für einen
> Schleifendurchgang
> und beim nächsten wieder überschrieben.
>
> String test1
> String test2
> (0..20).each{
> test1 = "Hallo Welt " + it
> test1 = "Hallo Welt " + (it * 2)
> }
>
> Die Argumente waren, wie vorher zu erwarten, die Performance sei
> dadurch besser, der Speicher sei nicht unnötig in Verwendung und es sei
> besser zu
> lesen. Ich habe gegen die Punkte Leserligkeit und Performance
> widersprochen

Hallo Jan,

hier geht es um wenige Taktzyklen haben oder nicht haben. Meine
Interpretation von CCD ist, dass Geschwindigkeit kein Argument gegen
sauberen Code sein darf. Schließlich verführt die äußere Deklaration zur
späteren nicht vorgesehenen Nutzung der Variablen.

Unter C# gibt der ReSharper in so einem Fall darum den berechtigten
Hinweis, dass die Variable weiter innen deklariert werden kann.

Grüße,
Mario Noack

Ralf Westphal

unread,
Dec 12, 2012, 4:17:43 AM12/12/12
to clean-code...@googlegroups.com
Performance? Das sagt CCD: Vorsicht vor Optimierungen!
Wie von Stefan schon erwähnt: erst optimieren, wenn nachweislich Suboptimalität herrscht, also zu schlechte Performance.

Das Argument deines Kollegen ist ein Reflex aus einer Zeit... ja, ich weiß gar nicht, wie alt dein Kollege dafür sein müsste, dass ihn sowas geprägt hat. Außerdem halte ich es für ein Argument, das nicht auf der Höhe der Zeit des Compilerbaus ist. Dein Kollege müsste nämlich erstmal zeigen, dass es bei Maschinencode, der am Ende zur Laufzeit von der CLR JIT erzeugt wird, überhaupt einen (speicherplatzmäßigen wie performancerelevanten) Unterschied macht, wo die Deklaration stattfindet.

Bitte ihn doch einfach mal, diesen Nachweis zu bringen :-)

Womit wir wieder beim Messen sind. Suboptimalität muss gemessen werden. Geschieht das nicht, sind andere Werte wichtiger, zum Beispiel Lesbarkeit.

Und da stimme ich auch Stefan zu: die Lesbarkeit sinkt (der Wert der Evolvierbarkeit ist damit kompromittiert). Der Scope der Variablen ist nicht klar. Wenn sie nur für den Code innerhalb der Schleife relevant sind, sollte genau das ausgedrückt werden. Das steckt im Principle of Least Astonishment drin.

Bei C# wären natürlich auch nicht die Sprachfeatures ausgereizt. Denn da könnte man ohne Probleme so formulieren:

(0..20).each{
    var test1 = "Hallo Welt " + it
    var test2 = "Hallo Welt " + (it * 2)
}

(Mal davon abgesehen, dass der Code ja gar nix tut ;-)


Am Dienstag, 11. Dezember 2012 15:43:42 UTC+1 schrieb Jan Schumacher:
Hallo!

Wollte mich mal kurz vorstellen: Ich bin Jan Schumacher, arbeite für ein
Unternehmen in dem wir seit kurzem die Regeln des CCD anwenden und
damit experimentieren. Ich programmiere seit ca. 2 Jahren mit Groovy und
Grails, davor, so gut wie ausschließlig, mit Java.

Es gab heute während einer Code Review eine Diskussion mit einem Mitentwickler bei
der es darum ging ob es schönerer oder schlechterer Code ist Variablen
mit Objekten innerhalb einer Schleife oder ausserhalb einer Schleife zu deklarieren.
In unserem Beispiel werden die Objekte allerdings nur für einen Schleifendurchgang
und beim nächsten wieder überschrieben.

String test1
String test2
(0..20).each{
    test1 = "Hallo Welt " + it
    test1 = "Hallo Welt " + (it * 2)
}

Die Argumente waren, wie vorher zu erwarten, die Performance sei
dadurch besser, der Speicher sei nicht unnötig in Verwendung und es sei besser zu

Daniel A.

unread,
Dec 12, 2012, 5:08:14 AM12/12/12
to clean-code...@googlegroups.com
Hallo,

ich möchte mich den anderen Kommentatoren anschließen und noch kurz auf eines hinweisen: Durch den besser sichtbaren Scope (wenn die Vars in der Schleife stehen) wird ggf. auch zur Extraktion ermutigt, da man mit einem Blick sieht, was alles raus kann und die Sicherheit hat, dass es nur für die Schleife genutzt wird. Häufig sind nämlich extrem viele Schleifen-Vars ein Hinweis darauf, dass die Methode mehr als nur eine Aufgabe erfüllt.

Grüße
Daniel
Message has been deleted

Robert Niemann

unread,
Dec 12, 2012, 3:00:22 PM12/12/12
to clean-code...@googlegroups.com
ItemType item;
  .
  . //some code here ...
  .
for ( int index = 0; index < anArray.length; index++ ) {
   item = anArray[index];  // Get one of the values from the array
     .
     .  // process the item
     .
}

extract method:

ItemType item; //WTF
  .
  . //some code here ...
  .
for ( int index = 0; index < anArray.length; index++ ) {
    processItem(anArray[index]);
}

:-(

for ( int index = 0; index < anArray.length; index++ ) {
   ItemType item = anArray[index];  // Get one of the values from the array
     .
     .  // process the item
     .
}

extract method:

for ( int index = 0; index < anArray.length; index++ ) {
    processItem(anArray[index]);
}

:-)

Reply all
Reply to author
Forward
0 new messages