Spartanisch Programmieren - von Stefan Lieser

Stefan Lieser schreibt in seinem Blog, er wäre ein Freund des spartanischen Programmierens. Ich kann mich ihm dort nicht anschließen, da ich lieber Code schreibe, der sich lesen lässt; Variablen bekommen Namen, die auch ein Außenstehender versteht, Code wird kommentiert, es wird mit Freizeilen zur Strukturierung gearbeitet etc. Aber das ist, wie Stefan bereits schrieb, eine persönliche Einstellung. Wenn sie nicht durch Implementierungskonventionen erzwungen oder verboten wird.

Weshalb ich mich jedoch aufgefordert fühle, auf seinen Blogpost zu antworten, ist sein Fast-Exit-Beispiel. Um eine große Verschachtelungstiefe zu vermeiden, schreibt Stefan lieber viele Exits in einer Funktion, statt seinen Code ordentlich zu strukturieren. Zuerst ein schlechtes Beispiel (von Stefan ebenfalls als schlecht angesehen):

public void DoSomething() {
  if (a) {
    if (b) {
      if (c) {
        DoItRealy();
      }
    }
  }
}

Nun seine Verbesserung (Stichwort Fast-Exit), mit der ich noch immer nicht einverstanden bin:

public void DoSomething() {
  if (!a) {
    return;
  }
  if (!b) {
    return;
  }
  if (!c) {
    return;
  }

  DoItRealy();
}

Und nun zwei Arten, die ich persönlich den beiden Vorangegangenen (nicht uneingeschränkt, aber meistens) vorziehen würde:

public void DoSomething() {
  if ( ( a )
    && ( b )
    && ( c ) )
  {
    DoItRealy();
  }
}

public void DoSomething() {
  if (!a) 
  {
    Log("Not a");
  }
  else if (!b)
  {
    Log("Not b");
  }
  else if (!c)
  {
    Log("Not c");
  }
  else
  {
    Log("All requirements complied.");
    DoItRealy();
  }
}

.NET | C | C# | Common | Snippet

Tuesday, July 22, 2008 7:01:54 PM (W. Europe Daylight Time, UTC+02:00)

Comments [1] | Trackback

Friday, August 01, 2008 7:44:11 PM (W. Europe Daylight Time, UTC+02:00)

Spartanischer bedeutet nicht schlecht lesbar ;-) Auch mein Ziel ist es Code zu schreiben der gut lesbar ist. Natürlich sind Namen etwas ganz wichtiges, und natürlich dienen Leerzeilen dazu Struktur in eine Methode, Klasse, etc. zu bringen.
Mit Kommentaren habe ich so meine Probleme (xmldoc zur Dokumentation mal ausgenommen). Ein Kommentar im Code ist in der Regel ein Hinweis darauf dass die Struktur oder Namensvergabe noch verbessert werden kann. Kommentare sollten meiner Ansicht nach beschreiben WIE etwas getan wird, nicht WAS getan wird. So ist es z.B. sinnvoll einen nicht offensichtlichen Algorithmus zu erläutern. Aber ZUERST würde ich wieder versuchen ihn ohne Kommentar lesbarer zu machen.

Zum fast exit und deinen Beispielen: wenn Logging gefordert ist kann man das natürlich einbauen. Dann würde ich trotzdem hinter jeder Log-Zeile mit return raus hüpfen und das "else if" abkürzen.

Herzliche Grüße,
Stefan

Stefan Lieser

OpenID
Please login with either your OpenID above, or your details below.

Name
E-mail
Home page

	Remember Me
Comment (Some html is allowed: `a@href@title, strike`) where the @ means "attribute." For example, you can use <a href="" title=""> or <blockquote cite="Scott">.

Live Comment Preview