[php] Codeformatierungsphilosophie (was: Selbstkritik)

[Yannik Hampe]

Christian Knorr wrote:
> Am Mittwoch 09 Juli 2008 20:03:55 schrieb Christian Knorr:
>> [CODE]
>> if ( isset($_POST['language'])) {
>>         $language = $_POST['language'];
>>         } else {
>>                 $language = false;
>>                 }
>> [/CODE]
> (natürlich ohne Semikolon im if(isset()) ;-) )
> 
> [CODE]
> // (Es folgt ein Einzeiler)
> if ( isset($_POST['language'])) $language = $_POST['language']; else \
> $language = false;
> [/CODE]
> 
> Letzteres ist wohl Ressourcen schonender und "besser" bei 15 Variablen und 
> mehr. Aber auch unübersichtlicher. Ersteres lässt sich hingegen fast auf 
> einen Blick "lesen".
> Aber wie macht’s der Profi? Wie gesagt ist es mir nicht egal ob es 
> funktioniert, egal wie. Wenn schon, dann richtig.

Wieso meinst du, dass Letzteres wohl Ressourcen schonender ist? Wegen 
den fehlenden geschweiften Klammern? Also gut, es ist sicherlich 
schonender, weil der Quelltext einfach kürzer ist und der parser damit 
weniger Bytes durchsaugen muss, aber wir sprechen hier von nicht 
messbaren Unterschieden. Also wenn du da ein 0,0001%igen 
Performancegwinn rausholst, dann .... dann hast du was gewonne :-D.

Und der Profi... Da kann man sich stundenlang drüber streiten. Ich kann 
dir nur sagen, wie ich es machen würde und wieso ich es so machen würde 
und dann können dir ganz viele andere Leute noch sagen, wie sie es 
machen und wieso... Im Endeffekt ist das ganze nicht so wahnsinnig 
wichtig, weil es code-formater gibt, die du konfiguarieren kannst und 
wenn irgendwer mit code daher kommt, den du fürchterlich findest, dann 
lässt du mal einen formater mit deinen Einstellungen drüberrasseln und 
schon ist alles wie gewohnt.

Ich würde es jedenfalls so schreiben:

if (bedingung) anweisung;
else andereAnweisung

Denn in dem Fall kann ich das Konstrukt direkt voll überschauen. Ich 
sehe direkt, wenn die Bedingung wahr ist, dann die erste Zeile, sonst 
die zweite.
Und wenn es mehrere Anweisungen sind, dann so:

if (bedingung)
{
   anweisung1;
   anweisung2;
}
else
{
   anweisung1;
   anweisung2;
}

Das ganze wäre natürlich Papierverschwendung, wenn man dies ausdrucken 
würde, aber das will ich ja nicht ;-).
Das gute daran ist: Die Geschweiften Klammen fallen sofort ins Auge, die 
Kontrollstruktur hebt sich von den Befehlen ab und ich sehe sofort, von 
wo bis wo der Block geht. Bei der Formatierung:

if (bedingung) {
   bla;
   blubb;
} else {
   bla;
   blubb;
}

fällt mir das schon viel schwerer. Denn die sich öffnenden schweifenden 
Klammern sehe ich nicht sofort. Da muss ich dann genauer hinsehen. Auch 
das else würde mir eventuell entgehen, weil es gleichweit wie die 
Anweisungen eingerückt ist und die geschweiften Klammern vor und hinter 
anderen Ausdrücken nicht so ins Auge fallen (das könnte man natürlich 
verbessern in dem man die Anweisungen noch weiter einrückt, aber so gut, 
wie meine Lösung finde ich das dann immernoch nicht).

Das ganze kann man noch mit ein paar Gedanken über die Funktionsweise 
des Auges ergänzen: Das Auge sieht nur in einem sehr begrenzten Bereich 
wirklich 100%ig scharf. Aussenherum ist es alles unscharf. Das nehmen 
wir nicht wahr, aber irgendwelche Forscher haben mit solchen Sachen mal 
viel Zeit verbracht :-). Ich finde, dass sich meine Struktur auch 
unscharf sehr gut lesen lässt. Ich kann mich ein paar Meter hinter 
meinen Bildschirm stellen. Soweit, dass ich die Buchstaben gerade 
nichtmehr lesen kann. Und ich kann meine if-else Struktur immernoch 
erkennen und genau sehen, von wo bis wo der Block geht. Bei der anderen 
Struktur kann ich das else nichtmehr lesen und es sieht so aus, als 
würde alles zum if gehöhren und es würde garkein else geben.

Auch ganz interessant ist, dass dein Auge blind ist, während du es 
bewegst. Ein paar Forscher haben das herausgefunden indem sie Leute vor 
einen Bildschirm mit Text gesetzt haben, deren Pupillenbewegungen 
gemessen haben und immer, wenn sie die Pupillen bewegt haben, haben die 
einzelne Wörter auf dem Bildschirm , wo der Probant gerade nicht am 
lesen ist ausgetauscht. Und haben festgestellt, dass diese Änderungen 
nicht wahrgenommen werden. Auch dies merken wir nicht, weil das Gehirn 
uns solange ein Bild vorhält, wie wir die Pupillen bewegen. Dieses Bild 
ist allerdings natürlich wieder unscharf. Wenn man dann seine Augen sehr 
schnell über Quelltext hinweg bewegt (weil man einen Fehler sucht oder 
gerade dabei ist sich generell ein schnelles Bild davon zu machen, was 
in dem code so passiert), dann nimmt man eine ganze Menge unscharfe 
Bilder wahr. Und die Formatierung kann dazu beitragen, dass man mit 
diesen unscharfen Bildern eine Menge anfangen kann.

Ich habe mich in der Vergangenheit in meinen Codestil bestätigt gesehen, 
da ich oft den code von Freunden gedebuggt habe, die ihren Fehler in 
deren Formatierung (so in Richtung meines zweiten Beispiels) einfach 
nicht wahrgenommen haben, ob wohl die häufig simple Dinge waren (zum 
Beispiel falsch gesetzte geschweifte Klammer) ich diesen Fehler aber 
nach ein wenig Umformatierung sofort erkennen konnte.

So... Jetzt habe ich viel mehr geschrieben, als ich eigentlich wollte. 
Ist ja fast eine komplette Abhandlung über die Philosophie des 
Codeformatierens geworden.
Aber gut. Du kennst jetzt meine Meinung und du weisst wieso ich diese 
vertrete und vielleicht trägt ja noch jemand, der den anderen Stil 
vertritt seine Meinung bei (fänd ich echt gut, denn bisher war das 
einzige, was ich mal gehört habe "ich finde, dass die { da sonst so 
verloren aussieht" ;-)).

> 
> Danke schonmal, Chris......

Yannik