Re: code style

Gidion said...
> Hallo,
>
> ich habe gerade mal meinen Code mittels PMD und checkstyle prüfen
> lassen.
>
> hierbei sind für mich ein paar Fragen aufgekommen.
>
>
> was ist warum wieso weshalb besser, bzw wieso sollte man eher dies
> verwenden:
>
> 1. if oder switch (bevorzugt in Fall von enums):
>
> public class IfTest {
>
> 	public enum Test{FALL1,FALL2};
>
> 	public static void main() {
> 		testIf(Test.FALL1);
> 		testSwitch(Test.FALL2);
> 	}
>
> 	public static void testIf(Test test) {
> 		if (test.equals(Test.FALL1)) {
> 			return;
> 		} else {
> 			return;
> 		}
> 	}
>
> 	public static void testSwitch(Test test) {
> 		switch (test) {
> 			case FALL1: {
> 				return;
> 			}
> 			case FALL2: {
> 				return;
> 			}
> 		}
> 	}
> }

Kommt auf den Fall an. Wenn ich sicher sein will, dass ich keinen
versehentlichen Fall-Through bei dem Switch haben möchte,mache ich ein:

if(test == Test.FALL1){
//..
}else if(test == Test.Fall2){
//..
}

Möchte ich einen Fall-though haben, oder denke ich, dass dieser später
ggf nötig oder sinnvoll wäre, bevorzuge ich switch:

switch(test){
case Fall1:
case Fall2:
//..
break;
case Fall3:
//...
}


> 2. Fall:
>
> public Test getTest(TestId testId) {
> ...
> }
>
> oder
>
> public Test getTest(final TestId testId) {
> ...
> }
>
>
> wie denkt ihr darüber ??

Ich mache alles final, was nur einmal zugewiesen werden soll.
Das mache ich aus mehreren Gründen:

1. Ausdruck:
Hat man sich erstmal dran gewöhnt, stechen einem Variablen sofort ins
Auge, die nicht final sind. Die Variablen, die Änderungen unterworfen
sind stechen also sofort hervor. Damit hat man immer einen Fokus auf
einen, wenn nicht den wesentlichen Teil des Algorithmus: die Variablen.
Der Quelltext transportiert so einfach viel besser, was der Code tut.

2. Refactoring:
Eigentlich könnte ich hier "1b" sagen: Weil Invarianten durch die
"final"-Modifier sofort erkennbar sind, sehe ich schneller, was ich
etwas umarrangieren kann. Natürlich erfordert das, wie bei 1, ein wenig
Gewöhnung. Ist der Blick einmal dafür geschärft, fallen diverse Muster
einfach besser auf.

3. Erreichbarkeit:
public void foo(final Bar bar){
SwingUtilities.invokeLater(new Runnable(){
public void run(){
bar.doSomething();
}
});
}

Ohne final-Modifier kompiliert das nicht.

4. Zwang zur Disziplin:
Lange Parameterlisten sind (und das sieht auch Refactoring-Guru Martin
Fowler so) möglichst zu vermeiden. Mit einem "final" am
Methodenparameter erscheinen die auch sehr lang und erfordern mehr
Tipparbeit, und weil zu lange Parameterlisten mit "final" extrahässlich
aussehen, überlegt man sich zwangsläufig wie man sie kleiner machen
kann, beispielsweise in dem man Objekte nicht zu schnell auseinander
nimmt, größere Parameterbündel als Parameterobjekt übergibt und
ähnliches.
Beispiel:
void paintSomething(Graphics g, int x, int y, int width, int height){
//...
}
sieht vielleicht noch akzeptabel aus, doch mit final-modifier offenbart
sich die eigentliche Hässlichkeit der Signatur:

void paintSomething(final Graphics g, final int x, final int y, final
int width, final int height){
//...
}

Man fühlt sich geradezu genötigt es umzuformulieren in:

void paintSomething(final Graphics g, final Rectangle area){
//...
}
Und das wäre selbst ohne "final" schöner als der ursprüngliche
Code.

Gruß,
-Wanja-

--
Klingon function calls do not have 'parameters', they have 'arguments' -
and they always win them.
[Nele Abels in dsg]
[ Auf dieses Posting antworten ]