// der php hacker

// archiv

Wenn Entwickler hassen: Was nervt euch?

Geschrieben am 18. Feb 2011 von Cem Derin

Der Mensch ist ein Gewohnheitstier. Auch wir als Entwickler sind davor nicht gefeit. Ich habe mehr als einmal die Erfahrung machen müssen, dass Entwickler sogar sehr viel häufiger ein Problem damit haben, aus festgefahrenen Strukturen auszubrechen oder sich mit “neuen” Herangehensweisen zu beschäftigen. Ob es nun die IDE, das verwendete Framework oder bestimmte Architektur-Ansätze sind.

An manchen Stellen jedoch stößt man an Punkte, die stoßen einem einfach sauer auf. Und das hat dann überhaupt nicht da mit zu tun, dass man “festgefahren” wäre, sondern ist ein ganz subjektives aber deswegen nicht weniger störendes empfinden. Kleines Beispiel (was ich neulich auch getwittert habe): Ich hasse es, wenn SQL-Aliase ohne “AS” angelegt werden. Das sieht ungefähr so aus:

SELECT
	myTable.row myRow
FROM
	table myTable
JOIN
	anotherTable yourTable
ON
	myTable.myRow = yourTable.id
WHERE
	myTable.anotherRow = 'value';

Da könnte ich mich wirklich auskotzen. Was mich auch auf die Palme bringt (und oft bei “Anfängern” zu sehen ist): wenn Parameter ohne Leerzeichen direkt hintereinander geschrieben werden. Beispiel:

	function($param1,$param2,$param3)

Ganz übel wird es, wenn dann auch noch geschachtelt wird:

	function($param1,$param2,foo($bar,function($batz)))

Grauenhaft. Es tut mir schon weh, dass hier nur exemplarisch zu schreiben. Ich weiß zum Beispiel, dass ein namentlich nicht genannter Kollege jedes mal in einer Halb-Zwangshandlung an den Leerzeichen rumfummelt, bevor er sich den Code überhaupt angucken kann.

Und deswegen: Was nervt euch tierisch an?


#001
18. Feb 2011
Martin Kuckert

Mit Formatierungen habe ich kaum Probleme… Nachdem ich in der IDE letztere automatisch korrigieren haben lasse…

Aber mit deinem SQL-Beispiel hast du recht, da geht es mir ähnlich. Oder Variablennamen in einer anderen Schreibweise…


#002
18. Feb 2011
knalli

Abgesehen vom SQL: Das ist alles eine Sache von a) eigener Perfektion von schönem Code oder b) einem geeigneten (Auto-)Formatierer in der IDE/dem Editor.
Ich hasse es auch, unformatierten Code lesen zu müssen. Nicht “schön formatierter”, aber einheitlich formatierter Code kommt danach :p

Was SQL “as” angeht. Das ist teilweise sogar richtig als “noise” dokumentiert, bspw. Postgres. Und ich kann mich an einen Fall erinnern, wo im generischen SQL in einem Framework sogar AS entfernt wurde (mit einem netten As-Witz :p), weil es irgendwo sogar Probleme machte. Nichtsdestotrotz sollte man SQL formatieren, bspw. nach deinem Vorschlag.

Schlimm ist auch:
* Deutsche Variablen/Funktionen mittendrin;
* offensichtliche Copy-Paste-Aktionen, die einem in den Augen wehtun;
* größere Codestellen a la $i, $ixa und Co. :)


#003
18. Feb 2011
Cem Derin

Was mir da noch einfällt: Etwas, dass ich auch überhaupt nicht leiden kann, dummerweise aber aus irgend einem Grund selbst immer wieder mache: Wenn ich Code “refactor”, Kommentiere ich den “ursprünglichen” aus – und lasse es dann auch so stehen. Ich versuch das zwar immer zu bereinigen, aber ich vergesse es regelmäßig ;)


#004
18. Feb 2011
knalli

Du hast recht, ich ergänze: Große auskommentierte (nicht zwingend durch ein Refactoring) Codezeilen. Das kommt sogar noch vor leeren Absätzen — “für die Übersicht”.

#005
18. Feb 2011

[...] This post was mentioned on Twitter by Cem Derin, Christian. Christian said: Wenn Entwickler hassen: Was nervt euch? http://j.mp/eeOGK7 #gr2t [...]


#006
18. Feb 2011
TH

Ich bekomme die absolute Kriese bei zu langen Kommentaren. Da liest man 400 Wörter um zu erfahren, dass die Funktion TRUE/FALSE zurück gibt.


#007
18. Feb 2011

Ich nenne das keine Zwangshandlung sondern konsequentes Befolgen der “Pfadfinderregel” – hinterlasse Code sauberer als du ihn vorgefunden hast. Hier eben sauber im Sinne von Codeformatierung, das ist ja nicht nur persönlicher Geschmack sondern über verschiedene Richtlinien hinaus Konsens.
Eine häufig zu sehende Sache in PHP wo es mir immer in den Fingern juckt ist z.B. das weglassen von “public” in öffentlichen Methoden.


#008
18. Feb 2011
netdesk

Top 3:
#1) Scripts mit 1000+ Zeilen. Ohne eine einzige Funktion. Inklusive x-fachem Missbrauch von Copy&Paste. Ohne (ordentliche) Einrückungen. Ohne sprechende Variablennamen. Dafür MIT Tabellenlayout…seh ich fast täglich…

#2) SQL-Queries: Über ein AS oder nicht AS (das ist hier die Frage *g*) beschwer ich mich gar nicht mehr. Mir würds schon reichen, wenn die Aliase sprechend wären. Ich les täglich 20 zeilige Queries mit mehreren Joins, in denen für jede gejointed Tabelle a, b, c, usw. als Alias vergeben wird. Besonders lustig ist das dann bei der Interpretation der WHERE Klausel wenn man zig mal zwischen JOINs und WHERE Klausel hin und her schauen muss um sie zu verstehen.

#3) Lange SQL-Queries ohne Formatierung und in einer Wurst heruntergetippt. Natürlich inklusive den nervenden Dingen aus #2.

#2 und #3 in #1 macht einen Tag doch gleich viel schöner…


#009
18. Feb 2011

Also mit dem SQL “AS” hab ich jetzt auch kein Problem, ob man es verwendet oder nicht. Viel wichtiger finde ich auch, dass der Alias sprechend ist.
Und für die Leerzeichen bei den Funktionsparameter sollte man sich wohl auf einheitliche Coding Standards, damit sollte das auch abgedeckt sein.
Was ich noch viel schlimmer finde, sind nichtssagende SVN Commit Kommentare. Die Kommentare sind ja eigentlich dazu da, im Nachhinein nachvollziehen zu können, warum die Änderung gemacht wurde, wenn dann aber sowas wie “Bug gefixed” drin steht, könnt ich kotzen!


#010
18. Feb 2011
knalli

Hihi.. sind wir nicht alle ein bisschen Codenazis? :p

bzgl. VCS (-Comments:)
* in Multiprojektumgebungen den Projektnamen verschweigen
* die Sprache nach Beliebigen wechseln
* unsinnige Splits vornehmen, etwa Dateiweise weil “man nicht alle zusammen aus verschiedenen Verzeichnissen markieren kann”


#011
18. Feb 2011
stefket

Das mit den fehlenden Leerzeichen zwischen den Parametern geht mir auch ziemlich auf die Nerven.

Was mich auch nervt sind z.B. 100fach verschachtelte Methoden / Funktionen.


#012
18. Feb 2011

Trinitäts-Operatoren. Ihr wisst schon.

Wenn ? Dann : Sonst

Am besten noch verschachtelt, wie es ein mir bekannter Programmierer gerne macht.

WennA ? (WennB ? DannC : SonstB) : SonstA

Hab ich schon bis zu drei Level verschachtelt erlebt. Ganz ehrlich: kein Gericht würde mich in dem Fall wegen Mordes verurteilen, oder?


#013
18. Feb 2011
knalli

Verschachtelt und komplex.. unschön. Auch Methodenaufrufe.

Aber für kurze, knappe Statements IMHO okay. Aber durchaus schon mal in Code-Policies drin :)


#014
18. Feb 2011
jens

Programme in denen alle Variablennamen mit “my” beginnen. (Erlebt bei meinem vorletzten Arbeitgeber: “$myA, $myB, $myC”) :-(


#015
18. Feb 2011

Wenn Entwickler Code weiter geben, dann sollten sie sich angewöhnen ihn quasi als Raw-Format weiter zu geben. Raw-Format würde bedeuten: Keine Leerzeichen, keine Einrückungen, keine Zeilenumbrüche oder andere Formatierungen.
Derjenige der sich den Code dann anschauen will, muss ihn sich erst mittels IDE/Programm in sein Wunschformat konvertieren.
Hintergrund: Menschen die eine IDE verwenden die Leerzeichen anstatt Tabs zum Einrücken verwendet. Das sieht spätestens dann wirklich lustig aus, wenn 3 Leute nacheinander das Script bearbeitet haben und jeder seine Einrückungen nach seinem Gusto vorgenommen hat.

Unendliche If-Statements. if( $a || $b || $c || $d || …. || $z ){…} elseif( $a1 || $a2 || $a3….)
Manchen Code kann man sich nur im Kino auf Breitbildleinwand anschauen. Das wirklich schlimme daran, mit etwas Nachdenken hätte man es vermeiden können.


#016
19. Feb 2011
Paloran

Ich weiß ja nicht ob du Netbeans nutzt, aber dort gibt es eine voll konfigurierbar Code Formatierung welche z.B. die fehlenden Leerzeichen ersetzt.


#017
19. Feb 2011
Z4ppy

m.a.: Generell bin ich ja mal deiner Meinung. Aber wenn du z.B. einen String “echo-st”, in dem du ein Wort je nach Bedingung in unterschiedlicher Farbe ausgeben willst, dann verwende ich das “short if statement” (den Namen mag ich lieber :P ) sehr gerne.

Ralf: Da stimme ich dir vollkommen zu :)

SQL Queries ohne Grossbuchstaben hasse ich. Am besten noch ohne jegliche überflüssige Leerzeichen, denn die würden ja zu (unerwünschter) Lesbarkeit führen…
mysql_query(“select t.*,tb.field from table t left join othertable tb on t.id=tb.tid where t.name=’fritz’ order by t.id”);

A propos Leerzeichen…
if ( ( $a < $b ) && ( ( $c < $d ) || ( $c == $e ) ) ) { echo 'true'; }
Keine Leerzeichen ist schlecht, da stimme ich euch zu, aber übertreiben muss mans ja auch nicht… Ich finde (insbesondere mit dem Klammernhighlighting in der IDE) folgende Variante schöner:
if(($a < $b) && (($c < $d) || ($c == $e))) { echo 'true'; }

Schön sind bei if statements auch doppelte und dreifache Verneinungen :D
if(!(($a = $b) && !(($c != $d) || ($c < $e) || !($c < $f)))) { echo 'true'; }
Alles klar, oder? :)

Ich mag es auch nicht, wenn im Code andere Sprachen als Englisch verwendet werden (Kommentare mal ausgenommen). Nachdem ja alle Standardfunktionen, Fehlermeldungen usw. (abgesehen von meinem Lieblingstoken T_PAAMAYIM_NEKUDOTAYIM) von PHP in Englisch benannt wurden finde ich es das sinnvollste, dies bei den eigenen fortzusetzen…
(Btw: Wieso ist der Text neben dem Haken beim Kommentieren hier Englisch? ^^)

Und natürlich fehlende Einrückungen – oder inkonsequente (Leerzeichen/Tabulatoren-Kombi)…


#018
19. Feb 2011

1. CamelCase und Unterstrich getrennte Namen vermischt
2. my als Prefix für Namen von Variablen oder Sonstigem
3. unendlich verschachtelte logische Ausdrücke
4. Kommentare mit Falschinformationen
5. Sinnfreie Kommentare “Prüfen ob gesetzt” bei einem if(isset())


#019
20. Feb 2011

Was nervt?
Funktionen, die 1000 Zeilen lang sind. Variablen wie $n oder $v. Fehlende Leerzeichen auch bei Sachen wie $a=$b+1; und natürlich auch falsche Einrückungen. Mal zwei Leerzeichen, mal 4 und es können auch mal 6 sein. Was mich an meinen “Stil” aber am Meisten aufregt, ist, dass ich bei Funktionen oder Bedingungen mal mit Leerzeichen arbeite und manchmal nicht.
function blubb($param)
function blubber ($param)
if (Bedingung)
if(Bedingung)
Da konnte ich mir bis heute noch keinen einheitlichen Stil angewöhnen. Und werde es wahrscheinlich auch nie lernen. ;-)


#020
20. Feb 2011

Mir fällt spontan nix ein, wo ich mich drüber aufregen könnte. So lange es durchdacht und sicher ist, kann mich da nicht viel schocken.

Mein Editor formatiert aber auch jeden Code automatisch auf mein Format. :-)

//Edit: Was mich hier jetzt spontan ankotzt ist, dass ich Kommentare ohne Javascript nicht absenden kann und auch keine Fehlermeldung bekomme, sondern einfach nur nach oben hüpfe. Über sowas könnte ich mich stundenlang aufregen. Javascript ist barrierefreies einzusetzen, VERDAMMT!!!111einself


#021
21. Feb 2011

- fehlende Versionsangaben
- fehlende Autor-Kennzeichnungen/Kontaktdaten
- fehlende oder veraltete „Build“-Anleitungen („du brauchst Xy _in Version abc_ und Schreibzugriff für das Verzeichnis def“)
- Rummüllen im globalen Namensraum (etwa mit Konstanten)
- sinnfreie Singletons
- nicht E_STRICT-compliant Code
- print “$text”; // Grr
- variable Variablen
- unnötig hohe Komplexität (x Variablen auf y Zeilen in einem Namensraum)
- Festhalten an PHP4
- Funktionen/Methoden, die nicht mit einer return-Zeile enden

Nummer 1 ist ganz klar:

- undokumentierte Cleverness

Die meisten Dinge kann ich auf Autopilot anpassen, sowas leider nicht.


#022
21. Feb 2011

@mermshaus: Was sind denn sinnvolle Singletons? Also wenn ich diesen Artikel (http://gooh.posterous.com/singletons-in-php) Glauben schenken soll, dann ist jedes Singleton überflüssig.

Mir fällt noch ein: Code- und Style-Fundamentalisten. Man kann die Kirche auch mal im Dorf lassen. Der eine oder der andere Coding-Styles (oder Pattern) ist nicht der Heiligen Gral und muss nicht bis aufs Blut verteidigt werden.


#023
22. Feb 2011

print “$text”; hätte noch HTML-Code mit einfachen Anführungszeichen um Attributwerte enthalten sollen. Der wurde geschluckt.

Mit dem „nicht auf return-Zeile enden“ meinte ich beispielsweise sowas:

function f($x) { if ($x === 1) { return true; } else { return false; } }

@Ralf: Ja, das „sinnfrei“ kann meinetwegen weg. Ich meinte auch eigentlich „global state“ allgemein, nicht speziell Singletons, wo ich noch mal drüber nachdenke. Ich habe beispielsweise kürzlich versucht, einen alten Code als Library zu verpacken, der an vielen Stellen Methoden einer Hilfsklasse statisch anspricht. Das ist eklig zu refaktorieren, wenn das an 100+ Stellen geschieht und die Methoden teilweise statische Klassenvariablen nutzen.

Weniger stören mich die Singletons etwa im Zend Framework, da ich da pragmatisch denke: „Kommst du nicht drumrum, wenn du das Framework nutzt.“


#024
25. Feb 2011
Cem Derin

@Oliver: Reg dich ruhig auf, kein Ding. Das ist mein privates Blog, hier kann ich machen was ich will. Und wenn ich alles in Flash baue ist das immer noch mein Bier ;)

Konkret bin ich übrigens immer noch nicht dazu gekommen, das wieder zu fixen, im Backup war leider noch die alte Version. Vielleicht hab ich ja demnächst Lust mich darum zu kümmern. Ich würde aber nicht drauf wetten, da ich derzeit an einem neuen Layout arbeite. Da sollte sowas aber nicht vorkommen ;)


#025
03. Mrz 2011

Zu deinem letzten Punkt: Mich nerven auch zu viele Leerzeichen:

if ( $a == $b ) {
do( $that , $andStuff ) ;
}


#026
03. Mrz 2011

da muss ich eher sagen: zu wenig Leerzeichen! Dein Beispiel war bis auf das Leerzeichen vor , und ; schon ok finde ich. Das Gegenbeispiel sieht auch irgendwie kaputt aus oder? Sowas hab ich in Projekten aber schon gesehen:

if($a==$b){do($that,$andStuff);}


#027
12. Mai 2011

Sag mal bist du zu blöd SQL zu lesen oder wie ? Das weiss doch nun echt jede Sau das man das AS bei SQL weglassen kann, und schliesslich sparrt man dadurch ja 3 Bytes code, was sich im nachhinein auch auf die Performance auswirkt.
Und was die Leerzeichen angeht, anscheinend bist du auch zu Blöd den anderen in deinem Projekt zu zeigen wie man den PHP Code Sniffer benutzt, oder ihn im Prozess zu integrieren.

Und bitte nimm das jetzt nicht ernst, ich wollte nur zeigen meckern kann man immer :-)
Das mit AS finde ich auch schöner, leerzeichen haben eigentlich auch ihre berechtigung aber ich würde jetzt nicht behaupten ich hätte noch nie eins vergessen.


#028
01. Jun 2011
Fin

Ich mag es nicht, wenn Funktionen nicht dokumentiert sind oder ganz oft auch zu sehen weder Type Hinting noch sinnvolle Variablennamen. Auch ist Einrücken oder zu wenig Leerzeichen ein bekanntes Problem!

Jeder Programmierer sollte sich einen einfachen und übersichtlichen Stil angewöhnen!


#029
02. Jun 2011
Jannik

Im großen und ganzen nervt mich genau das, was du gerne willst. Ich denke es gibt einfach Programmierer, die die Arbeit lieber ‘kompakt’ sehen, und welche, die es lieber aufgefächert mögen.
Ich gehöre zu den ersteren. Wenn mich was aufregt, dann sind es z.B. CSS-Dateien, die max. 30 Zeichen Breite haben, aber dafür 100 Zeilen länge, obwohl man sie auch schön kompakt auf 10-15 Zeilen anzeigen könnte.
Ebenso gehts mir bei PHP und SQL… eine einzelne (nicht ewig lange) Anfrage noch in 10 Zeilen zu splitten ist nicht mein Ding. Wenn sie so lang wird, dass sie breiter als der Bildschirm ist, dann lohnt sich eine neuerliche Strukturierung.
Kurz gesagt, ich nutze gerne die Bildschirmbreite aus.


#030
12. Jul 2011

Ganz nervig ist auch die umgedrehte Verzweigungsprüfung:

if(‘de’==$language) {
do();
}

// kommentieren

// senden
theme von mir, software von wordpress, grid von 960 grid system. funktioniert in allen browsern, aber der safari bekommt das mit der schrift am schönsten hin.