wuetender-junger-mann.de

Das neue Ding in der Softwareentwicklung (jedenfalls für heute) ist der Emo Programmer. Kathy Sierra und David Heinemeier Hansson publizieren dieses Werk demnächst bei den Pragrmatic Programmers.

DHH hat sich in zwei Posts hier und hier zum Thema “Entreprise”-Applikationen geäußert. Und er trifft damit den Nagel auf den Kopf. Es wird allerlei Brimborium gemacht, tausend Buzzwords verwendet und keine Rücksicht auf reale Gegebenheiten genommen. Schon allein die Frage wodurch man sich zum Business Analyst/ Architect / Programmer etc. qualifiziert ist erschreckend. Erfahrung mit irgendwelchen Produkten – Abstraktionsvermögen, kommunikative Fähigkeiten, technisches Hintergrundwissen – alles egal.

Ich bin heute über die PDF-Zeitschrift Object View gestolpert. Sieht interessant aus.

Gestern habe ich ein wenig im Why ‘s (Poignant) Guide to Ruby  herumgelesen. Die Grundidee besteht darin, die Programmiersprache als leicht formalisierte Sprache  zur Problem- und Lösungsbeschreibung zu betrachten und nicht als Implementierungswerkzeug für ein in natürlicher Sprache gehaltenes Design. Einen ähnlich Ansatz propagiert Leo Brodie in Thinking Forth – A Language and Philosophy for Solving Problems.  Steile These des Tages daher: “Ruby ist das neue Forth”.

Den Rest des Tages habe ich auf nerdischere Art und Weise genutzt und meinen Parser- und Syntaxbaumgenerator MetaGen in einen präsentablen Zustand gebracht.

Es gibt ein Beispiel für die Auswertung einfacher algebraischer Ausdrücke und ein hübsches Tutorial am Beispiel einer Konfigurationsdatei.

Das Ding erzeugt Java Quelltext und der erzeugte Code benötigt die antlr Laufzeitumgebung.

The deadliest weapon in the world is a brilliant developer and his IDE.

Habe mir gerade noch das Refactor-J Plugin dazugekauft – großes Tennis.

* The literal syntax is much too meagre. Ther is no Map, no Collection, no List, no multiline String,
no expression substitution in Strings.

* The standard libraries provide poor abstractions and little convenience.

* There is no clean systax for block closures.

* It’s statically typed without providing proper generics or some kind of double dispatch.

zeichnet sich nicht dadurch aus, dass sie Exceptions großzügig fängt und ins log schreibt. Das gilt auch für betwixt!

Wie hier schon zu lesen war bin ich ein großer Freund der Exception, auch als Kontrollstruktur (für den Ausnahmefall). Eben hatte ich wieder so einen Fall, in dem ich besser eine Exception geschmissen hätte ,statt mit false zu “returnen.” Das ging etwa so:

public boolean myOperation(){

  if (!preconCheck1){
    log("precon 1 failed")
     return false;
  }

  if (!preconCheck2){
    log("precon 2 failed")
     return false;
  }

 performActualOperation();
 return true;
}

Jetzt war es so, dass die Prüfung der Vorbedingungen immer umfangreicher wurde.

Nun wollte ich den Code etwas aufräumen, da noch einige Modifikationen notwendig geworden waren. Mein Instinkt sagte mir “Extract Method”, aber leider hat der Vorbedingungscheck mehrere Exitpoints. Ich müsste den boolean als Rückgabewert der Methode verwenden und nach aufruf prüfen und ggf. mit return false abbrechen.
Problem ich hatte auch noch einen echten Wert zurückzugeben, ganz abgesehen davon, dass mir meine IDE die Sache nur ohne das Flag geschenkt hätte.

Ich habe folgende drei Variante einer Methode implementiert und hatte einen erbitterten Streit, welche denn die klarste und wartungsfreundlichste sei. Daher würde ich gerne mal wissen, wie Ihr das seht. Also kommentiert recht eifrig!

Variante 1

private void updateActions(){
		boolean kundeSelected = kundenAuswahl.getSelection()!=null;
		removeKunde.setEnabled(kundeSelected);
	}

Variante 1a

private void updateActions(){
		removeKunde.setEnabled(kundenAuswahl.getSelection()!=null);
	}

Variante 2

	private void updateActions1(){
		if(kundenAuswahl.getSelection()!=null){
			removeKunde.setEnabled(true);
		} else {
			removeKunde.setEnabled(false);
		}
	}