Chimicherrychanga

Eine Frage des Code-Stils

Informatik von Seba

Kuroko und Code-Stil

Weil übersichtlich

Einrückung. Wer seinen Code nicht einrückt (HTML und CSS mal ausgenommen) gehört geschlagen und dazu verdonnert, sein nächstes Projekt komplett in Python[1] zu schreiben als erzieherische Maßnahme[2]. Ein böses Beispiel:

function foobar( $lorem, $ipsum ) {
	while( $lorem < 42 ) {
	$ipsum++;
	}
	$temp = doSomething();
	if( $temp == $ipsum )
	// Besonderer Bommel
	return 17;
	return 19;
}

Ja, du mich auch. Die beiden return sind besonders hübsch.

function foobar( $lorem, $ipsum ) {
	while( $lorem < 42 ) {
		$ipsum++;
	}
	$temp = doSomething();
	if( $temp == $ipsum )
		// Besonderer Bommel
		return 17;
	return 19;
}

Minimum an Leerzeichen. Mir wird ja gerne vorgehalten, ich übertriebe es mit Leerzeichen. An bestimmten Stellen sollte man aber wirklich, sonst …

function doSomething(){
	$foo='abc123xyz';
	$replace=array('abc','xyz');
	for($i=0;$i<2;$i++){
		$foo=str_replace($replace[$i],'',$foo);
	}
	return 2*$foo+4;
}

Autschen. Zumindest so viel sollte machbar sein, oder?

function doSomething() {
	$foo = 'abc123xyz';
	$replace = array('abc', 'xyz');
	for($i = 0; $i < 2; $i++) {
		$foo = str_replace($replace[$i], '', $foo);
	}
	return 2*$foo + 4;
}

Zeilenumbruch. Optische Abstände im Code helfen, zusammenhängende Blöcke zu erkennen oder schneller den Anfang und das Ende einer Funktion zu erkennen. Deswegen setze ich einen Zeilenumbruch oft nach den Variablendeklarationen und z.B. zwei Zeilenumbrüche zwischen den Funktionen.

/**
* Turns a string into a more URL suitable string.
*/
public static function ProcessString( $string ) {
	$umlaute = array( 'ä', 'ö', 'ü', 'ß' );
	$deumlauted = array( 'ae', 'oe', 'ue', 'ss' );

	$string = strtolower( $string );
	$string = str_ireplace( $umlaute, $deumlauted, $string );

	$string = preg_replace( '!\s|\.|_|:|,|;|/|\\\|\*|%|~|\^!', '-', $string );
	$string = preg_replace( '/[^a-z0-9-\+]/', '', $string );
	$string = preg_replace( '/[-]{2,}/', '-', $string );
	$string = preg_replace( '/^-|-$/', '', $string );

	if( $string == '' ) {
		$string = 'tag-1';
	}

	return $string;
}


/**
 * Another function doing something. You get the drift.
 */
protected function somethingElse() {
…

Keine geschweiften Klammern auslassen. Folgt auf eine Bedingung oder Schleife nur eine Anweisung, kann man die geschweiften Klammern rein technisch auch weglassen. Was hat man davon? Eine Zeile Code gespart? Donnerlütchen, bin ich beeindruckt. Vier Minuten später kommt eine Anweisung hinzu und die Klammern müssen doch gesetzt werden. Und dann vergisst man sie und allES FLIEGT EINEM UM DIE OHREN! BAM!![3] Hier ruht eine potentielle Gefahrenquelle, daher sollte man es sich nicht angewöhnen.

// SO NICHT
function foo() {
	$i = 0;
	while( $i++ < 10 )
		if( $i == 4 )
			bar();
}

// SO
function foo() {
	$i = 0;
	while( $i++ < 10 ) {
		if( $i == 4 ) {
			bar();
		}
	}
}

Weil nach Geschmack

Tabs vs. Spaces. Einrückung mit Tabs oder Leerzeichen. Es gilt nur: Nicht mischen. Danach kann es jeder halten, wie es ihm beliebt. Persönlich bevorzuge ich Tabs:

  • In den meisten Editoren ist die dargestellte Länge eines Tabs einstellbar.
  • Hat man einmal nur einen unfähigen Texteditor zur Hand: Viel Spaß beim Einrücken mit Leerzeichen.

Mein Punkt: Tabs gehen schnell und sind flexibel.

Wohin mit geschweiften Klammern. Zwei Varianten sind weit verbreitet für Funktionen:

function variante1( $a, $b ) {
	if( $a == $b ) {
		return 2 * $a;
	}
	return $a + $b;
}

function variante2( $a, $b )
{
	if( $a == $b ) {
		return 2 * $a;
	}
	return $a + $b;
}

Wie an Variante 2 zu sehen, geht es wirklich nur um die Funktion und die if-Bedingung ist nicht betroffen. Auf der einen Seite ein wenig inkonsequent, andererseits könnte es auch eine gewollte Unterscheidung sein. Ohnehin ist Variante 1 mein Ding.

Doch letztenendes

Über alledem ist vor allem eines empfehlenswert: Einheitlichkeit. Weist Code einen einheitlichen Stil auf, macht ihn das durchgängig lesbarer. Für so etwas existieren Coding Guidelines. Mein persönlicher Stil beruht zum Teil auf jenen von WordPress. Umgekehrt sind mir die Guidelines von Mono ein Graus.

Den angehenden Codern wünsche ich viel Erfolg bei der Suche nach ihrem Stil. Aber seid darauf gefasst, diesen bei späteren Teamarbeiten wieder zurückzustellen. Und auch wenn euch das Kotzen kommt – nie den Code anderer auto-formatieren. Das gibt böses Blut. ;)


[1] In Python gibt es keine geschweiften Klammern um zusammengehörige Anweisungen einzurahmen. Dies funktioniert alles über korrekte Einrückung.

[2] Was keine negative Äußerung gegenüber Python sein soll. Damit soll zum Ausdruck gebracht werden, dass Python in dieser Hinsicht vorbildhaft aufgebaut ist und zu guten Stil zwingt. So, besser Kai? ;)

[3] Uh, ja, ich hatte irgendwann keine Lust mehr weiter zu schreiben, aber wollte den Artikel doch noch zu Ende bringen. So etwas passiert dann.

8 Kommentare

  1. avatar Kai
    Na, also. Geht doch:)
  2. avatar Christoph
    Warum habe ich mir das überhaupt durchgelesen…


    Klingt aber alles plausibel und cool. BAM!
  3. avatar Twaldigas
    Ich könnte auch jedes Mal wahnsinnig werden, wenn ein Quelltext nicht richtig formatiert ist. Das einrücken und richtige setzen von Klammern sollte man einfach beherrschen, wenn man einen Quelltext veröffentlicht und möchte, dass andere ihn verstehen.
    Auf jeden Fall ein schöner Beitrag, den sich einige Entwickler mal durchlesen sollten. ^^

    Gruß Twaldigas
  4. avatar B
    hehe, Python als Strafe ist gemein^^
    Ich persöhnlich mag keine Leerzeichen, ich sehe nicht, was an deinem „autschen“-code so schlimm sein soll…
    und das mit den Geschweiften Klammern kann man als Kompromisslösung ja einfach immer an die letzte Befehlszeile direkt dranhängen, so eine neue Zeile mag ich nicht, bringt nicht viel, denn die Ebenen werden ja schon durch die Tabs dargestellt
    Aber mit den anderen „Lesbarkeitsmitteln“ stimme ich überein
  5. avatar Seba

    Ich persöhnlich mag keine Leerzeichen, ich sehe nicht, was an deinem „autschen“-code so schlimm sein soll…


    D:

    D:

    D:
  6. avatar Kelhim
    Kann ich alles so unterschreiben, ich arbeite allerdings, weil ich zu blöd und faul für andere Sprachen und ein auch nicht so tief in der Materie verwurzelter Anfänger bin, sowieso ausschließlich in Python. Wenigstens zum Glück der Einrückungen werde ich also gezwungen.

    Ansonsten schreibe ich ein Programm wie Prosa. Absätze strukturieren den Text sinngemäß oder dienen allgemein der Übersichtlichkeit. Und manchmal sind mehr Worte besser als weniger, eine strikte Wort- und Zeichenökonomie ist kein Wert an sich. Man kann die tollsten Einzeiler schreiben, aber irgendwann möchte man den Code auch noch mal lesen und verstehen.
  7. avatar CBiX
    Stimme dir zu 90% zu. Mit Leerzeichen gehe ich aber anders um…

    public function demoMethod($foo, $bar = true) {
        if($bar) {
            $this->someVar = $config->someConfig;
            $this->config->asdf($foo);
        } else {
            $this->config->reset($foo);
        }
        // no comment.
        return $this->someOtherVar;
    }

    Vielleicht habe ich das auch einfach aus der deutschen Sprache übernommen, wo man ja auch keine „Leerzeichen“ hinter öffnende und vor schließende Klammern setzt :D

    Naja, und Kurzschreibweisen in PHP muss ich mir noch abgewöhnen – wobei ich <?= $dasHier ?> einfach viel lesbarer finde :(

    (ich weiß nicht, ob dein Blog das korrekt darstellt, aber ich rücke immer mit 4 Whitespaces ein…)
  8. avatar Seba
    Im Deutschen oder überhaupt geschriebener Sprache käme mir das auch nie in den Sinn – mit einer Ausnahme, nämlich bei Smileys: (Um mal ein Beispiel zu zeigen. ;) )

    Die Kurzschreibweise ist schon ganz nett und in JSP ja z.B. auch völlig unbedenklich. In PHP steht uns halt der Sicherheitsaspekt im Weg, dass die shorttags je nach Server-Config deaktiviert sein könnten.

    (Die Leerzeichen-Einrückung wurde tatsächlich falsch dargestellt, ich habe das mal editiert.)

Und jetzt du

Do not fill in these four fields:







Name, Mail und URL sind freiwillige Angaben. E-Mail-Adressen werden weder veröffentlicht noch weitergegeben. Verwendbares HTML: <a href=""> <abbr title=""> <blockquote> <cite> <code> <del> <i> <em> <b> <strong>