Better WPF DataBinding with CalcBinding

If you are like me, you want to bind Boolean properties to Visibility properties. We implement IValueConverter and therefore increase the complexity in the system. The new Type has to be named and placed correctly and we have to make sure that there is no value converter that already does what we just created. How can we speed up and improve binding and value conversion?

Recently I came across the very sweet WPF library CalcBinding. It allows for custom binding expressions without the need for an IValueConverter implementation. It is a markup extension that lets us write inversions and calculations directly in XAML. Those binding expressions also support two way binding automatically. That prevents the ViewModel from getting all kinds of highly View-related properties, which can obfuscate the abstract view model. Just like the CodeBehinds did in preMVVM age.
In this blog post I give you a quick run through of all the features I find most impressive. You can easily install it with “Install-Package CalcBinding”. Once you import its namespace in the XAML you can take advantage of the new binding like below.

1

The screenshot above shows a multi binding together with arithmetic expressions to produce a single result. The screenshot below shows additional calculations that can be used inside the binding expression. Remarkably, you get the back conversion for free. Not all calculations belong to the View. Keep in mind that calculations in the view can not easily be unit tested.

2

The screenshot below shows how to bind a Boolean to Visibility. Visibility is a Type that lives in View-land and I do not want view-specific Types to be dependencies of my ViewModels. I believe the ViewModel should be as pure as possible. This way I can easily reuse them to support not only WPF views in a MvvmCross solution, for example. Unfortunately MvvmCross has its own framework specific Types like MvxCommand.

3

The screenshot below shows how to use the ternary operator (?:) within the binding expression to concatenate strings. This could be useful if the binding’s StringFormat is not enough.

4

There is one more thing I would like CalcBinding to do. If you already looked into AngularJS or compiled data binding in the Universal Windows Platform, you may like how they support binding to events. Would it not be great if we could do the same in WPF? Exactly. And here is how, utilizing the CalcBinding markup extension. Unfortunately, even though I created a pull request, this is not yet included/supported in the official version of CalcBinding.

5

CalcBinding is amazing. Especially when binding bool properties, it is a huge time saver. And on the side it keeps my ViewModels much cleaner and prevents them from turning into huge CodeBehinds. The only disadvantage I found is that while Visual Studio seems to accept the extensive binding expressions, ReSharper lists them as errors in its solution wide error analysis view. Maybe we can teach it to ignore those. For now, it has a very positive cost-benefit profile and I am going to continue using it. If you like it as well, give credit to Alex141 and star his github project at the link above.

Advertisements

Neuste Werkzeuge und Probleme

Kürzlich hatten wir in unserem Entwicklungsteam Schwierigkeiten nachdem einige Teammitglieder von ReSharper 9 auf ReSharper 10 aktualisiert haben. Es hat sich am Ende herausgestellt, dass die Werkzeuge gar nicht schuld waren. Dennoch hat dieser Zwischenfall eine Diskussion über die Team-interne Verwendung von Werkzeugen ausgelöst. Dabei wurde den Aktualisierten vorgeschlagen von der neuen Version wieder auf die alte zurückzugehen. Plötzlich stand das Installieren der neusten Versionen zur Debatte und es wurde von “der Team-Version” gesprochen. Das Thema haben wir auch in unserer Retrospektive diskutiert und hier wurde dann sogar von Installations-Veto und Installations-Verbot von den Softwarearchitekten gesprochen. Hiermit möchte ich meinen Standpunkt nocheinmal schriftlich klarstellen.

Es handelt sich bei diesem Thema eigentlich um zwei Themen. Das erste betrifft Probleme, die bei der Verwendung von Werkzeugen auftreten. Das zweite betrifft den Umgang mit neuen Versionen an sich. Wenn wir beides vermischen kommen wir zu vermeintlichen Lösungen die gar keine sind.

1. Thema: Tool-Probleme

Was sollten wir tun, wenn wir Probleme mit einem Werkzeug haben? Für mich ist die Antwort eindeutig: Beheben und zwar so schnell wie möglich! Ein Versions-Downgrade kann meiner Meinung nach nur das letzte Mittel sein. Wer ist dafür verantwortlich? Meiner Meinung nach die, die das problematische Werkzeug einsetzen. Und wenn das unbedingt eine bestimmte Person sein muss, dann bitte der CTO. In unserer Abteilung sehen sich die Architekten verantwortlich für den Einsatz von Entwicklungstools. Meiner Meinung nach ist das Schwachsinn. Entwicklungstools haben mit Softwarearchitektur nichts zu tun. Ich befürchte sogar, dass wir unsere Architekten mit Problemen, Fragen und Diskussionen rund um die Tools von den tatsächlichen und wichtigeren Aufgaben bezüglich der Softwarearchitektur abhalten und ablenken. Laut Wikipedia geht es bei Softwarearchitektur um

eine strukturierte oder hierarchische Anordnung der Systemkomponenten sowie Beschreibung ihrer Beziehungen

oder ähnlich

Strukturen eines Softwaresystems: Softwareteile, die Beziehungen zwischen diesen und die Eigenschaften der Softwareteile und ihrer Beziehungen.

Architekten kümmern sich nicht um die Werkzeuge der Bauarbeiter, das machen die Bauarbeiter selber.

2. Thema: Neue Versionen

Ich glaube unsere Architekten beschäftigen sich nur deswegen so viel mit Werkzeugen, weil es sonst keiner macht und sie es gerne kontrollieren wollen. Aber allein die Idee, vorzugeben welche Werkzeuge zu verwenden sind und welche nicht, finde ich höchst fragwürdig. Meiner Meinung nach widerspricht das der Selbstorganisation, dem elften Prinzip des agilen Manifests:

The best architectures, requirements, and designs emerge from self-organizing teams.

Ich meine damit nicht, welches Versionsverwaltungssystem das Team einsetzt oder welche Framework-Version der Buildserver nutzt. Diese Punkte sehe ich tatsächlich im Entscheidungsbereich der Team-übergreifenden Einheiten und den Kundenanforderungen. Aber die Version von Visual Studio und ReSharper sehe ich im Entscheidungsbereich der Teammitglieder. Schließlich kennen die ihre Werkzeuge und Konsequenzen am Besten. Das Argument für eine homogene Versionslandschaft ist Code-Kompatibilität und Pair-Programming-Vereinfachung. Beides kann ich gut verstehen und beides ist in der Realität auch mit heterogener Versionslandschaft kein Problem. Zusätzlich haben wir ja mit Versionskontrolle und CI ausreichende Sicherheitsmechanismen um selbst theoretischste Probleme auf diesem Gebiet zu verhindern.

Aber ist es sinnvoll das ein Teammitglied Visual Studio 2012 und ein anderes Visual Studio 2015 nutzt? Nein. Wo ist das Problem? Das Problem sehe ich in der alten Version. Meiner Meinung nach hat das Team ein doppeltes Ziel. Zum Einen sollten alle im Team die gleiche Version einsetzen und zum Anderen sollten alle die neuste Version einsetzen. Zu jeder Zeit? Nein, statt immediate consistency lieber eventual consistency. Es stellt sich also die Frage nach dem Zeitpunkt der Umstellung. Ich würde sagen, early adopters sofort um die neue Version im praktischen Einsatz zu evaluieren. Wenn es Probleme gibt sollten diese behoben werden (siehe Thema 1) und zwar von den early adopters. Dann sollte das restliche Team maximal zwei Sprints später ebenfalls umsteigen. Um das zu ermöglichen sollte die Verfügbarkeit einer neuen Version von den early adopters angesprochen und das Team damit über den Begin einer Evaluierungsphase informiert werden.

Warum stellen wir überhaupt um? Es geht dabei um Verbesserung und Innovation. Unter dem Strich ist die neue Version besser. Ansonst hätte es sie ja nicht geben müssen. Die neuen Versionen haben weniger Fehler und neue Features. Wenn man sich nicht mit den neusten Tools beschäftigt, kann man auch nicht wissen, wie diese das Arbeiten erleichtern und sogar beschleunigen. Zum Beispiel bietet Visual Studio 2015 mit dem Visual Live Tree und Delegates im Debug-Window zwei Funktionen auf die ich nicht mehr verzichten möchte. Und ReSharper 10 enthält Postfix Templates out of the box. Außerdem, wenn man immer am Ball bleibt ist es auch einfacher auf eine noch neuere Version umzusteigen, die besonders außergewöhnliche Features bietet. Das ist wie beim Mergen von Branches. Je länger man wartet, desto weiter laufen die Pfade auseinander und desto schwieriger ist es, diese wieder zu vereinen.

Es ist wichtig, dass wir hier alle am selben Strang ziehen und zwar nach vorne.

STP LabsDay 2015

Am Donnerstag und Freitag letzte Woche, dem 1. und 2. Oktober, habe ich am zweiten STP LabsDay teilgenommen. Die Firma für die ich arbeite veranstaltet diesen 24-Stunden-Hackathon jedes Jahr. Zusammen mit meinem Partner habe ich ‘einen’ alternativen Client für das STP KMS entwickelt, der im Browser und auf möglichst vielen Geräten läuft. Unser Ziel war es dabei nur eine Codebasis zu haben, plattformunabhängig.

Um dieses Ziel zu erreichen kamen entweder C# oder JavaScript in Frage. Mit Xamarin kriegt man C# auf Windows, Android, iOS und Mac und mit Silverlight in den Browser. Auf der anderen Seite läuft JavaScript sowieso schon im Browser und mit NW.js kriegt man JavaScript auf Windows und Mac und mit Apache Cordova auf Windows Phone, Android und iOS. Ich habe mich für JavaScript entschieden, da Silverlight mittlerweile uncool ist und das Silverlight-Plugin eh nicht mehr im Chrome läuft. Außerdem sehe ich C# jeden Tag und JavaScript nicht.

Was das Backend betrifft, konnten wir die externe Schnittstelle von STP KMS nutzen, sodass wir uns voll und ganz auf Client-Entwicklung konzentrieren konnten. Unser erster Prototyp lief nach ca. 7 Stunden dank NW.js und Apache Cordova auf allen uns zur Verfügung stehenden Platformen: Wir hatten Windows, Mac, Windows Phone, Android, iPhone und iPad dabei. Programmiert haben wir bis dahin wenig, die meiste Zeit ging für die Administration der Geräte und Deployment-Probleme drauf. Aber in diesem Prototyp hatten wir die Logik unter der Oberfläche mit AngularJS vollständig umgesetzt und uns um das Design überhaupt nicht gekümmert. Es lief dann zwar einwandfrei aber sah echt nichts aus. Also haben wir die restliche Zeit in UI-Design investiert und mit jQuery Mobile für Smartphones optimiert.

Wir hatten nach 24 Stunden eine harte Deadline. Aber das hat uns gereicht. Wir hatten sogar Zeit für Essen, Schlafen und Fitnessstudio. Dank Apache Cordova können wir unseren Client auch für BlackBerry, FirePhone, Tizen und alle anderen Geräte erzeugen, die wir heute noch gar nicht kennen.

Bei der Abschlusspräsentation des STP LabsDay haben wir dann die identische App auf Windows, Mac, Windows Phone, Android, iPhone und iPad gezeigt. Und das kam richtig gut an. Für unser Projekt “cross platform KMS-Aktensicht” haben wir anschließend zwei Awards gewonnen: Den “roadmapper”-Award (Kundenpreis) und den “leider geil”-Award (Zuschauerpreis). Ersteren hat ein echter Kunde der STP höchstpersönlich verliehen und für Letzteren haben alle Zuschauer der Ergebnispräsentation anonym abgestimmt. Den Vorstands-Award haben wir leider nicht mehr gewonnen, der ging an ein anderes Projekt. Dennoch haben wir mit modernen Web-Technologien in kurzer Zeit und ohne Vorwissen richtig viel erreicht und viele beeindrucken können. Und wir haben NW.js und Apache Cordova kennengelernt. Cross platform for the win!

WP_20151001_001
DSC_0105
DSC_0145

NDC Oslo 2015

I want to share a little about my first ever trip to Norway. Today I got back from Oslo, where I visited the NDC 2015 conference. Amazing conference, see some of the photos I took below. Everything else was a little too stressful.

It took me 6.5 hours to get from Karlsruhe to the hotel in Oslo. There I had to pay for the hotel room with my credit card because the hotel was not capable of dealing with the HRS booking my company did in advance. I did not sleep well because it doesn’t get dark in the nights. 11pm (first photo) in Oslo looks like 8pm in Karlsruhe and 3am looks like 9pm. It took me 7.5 hours to get from the hotel back to Karlsruhe.

I was at NDC on June 17th and 18th and those were two great days. The sessions of Ian Cooper and Udi Dahan inspired me the most. Now I need to digest and structure all the notes I took. Best conference I ever went to, thank you NDC! Hopefully I get to go again next year, different hotel maybe.

WP_20150616_001WP_20150617_002WP_20150617_010WP_20150618_001WP_20150618_004 WP_20150618_003 WP_20150618_002WP_20150617_007 WP_20150617_016WP_20150618_007WP_20150618_005 WP_20150617_014 WP_20150617_011WP_20150618_008 WP_20150618_010

“Ich will keine Leben retten”

Vor kurzem habe ich den Satz gehört: “Ich studiere Medizin, damit ich Leben retten kann.” Das hat mich zum Nachdenken gebracht. Studiere ich nicht Medizin, weil ich keine Leben retten will? Eigentlich ist Leben retten ja eine gute Sache, also warum tue ich nicht alles mögliche, um Leben retten zu können? Medizin studieren zum Beispiel. Und wieso steht in meinen Gedanken jetzt über meinem Leben die Überschrift “Ich will keine Leben retten”?

Zunächst einmal retten nicht nur Mediziner Leben. Leben werden auch von Hilfsorganisationen in Krisengebieten und sogar von Soldaten im Krieg gerettet. Es geht nicht nur um Leben retten. Es geht auch um Leben schützen, Leben unterstützen und Leben verschönern. Außerdem bedeutet der Begriff “Leben” mehr als nur körperliche Gesundheit.

Meiner Meinung nach geht es eigentlich darum, einen Beitrag zur Gesellschaft zu leisten. Einen Beitrag zur Gemeinschaft der Menschen. Nach Karlfried Graf Dürckheim hat der Mensch einen doppelten Auftrag.

  1. die Welt gestalten in Werk

  2. reifen auf dem inneren Weg

Die Gestaltung der Welt für die Gemeinschaft der Menschen wird dazu führen, das “Leben” gerettet, geschützt, unterstützt und verschönert werden können. Vielleicht nicht direkt von mir, aber dann indirekt über die nächste oder übernächste Instanz in der Wertschöpfungskette. Zum Beispiel rettet der Hersteller von Seife keine Leben, aber der Arzt, der sich damit die Hände wäscht. Die Antwort auf die oben gestellten Fragen sehe ich in diesem doppelten Auftrag.

Was denken Sie?

Null propagation for pre-C#6

C#6 will support null propagation. But what if a system is stuck on C#4 or C#5? Result.OrDefault is my take on simple null propagation for pre-C#6. It is open source under the MIT license meaning you can freely use and modify it.

Do you know requirements like “display the employee’s name in the invoice view”? Then probably your ViewModel code looks a lot like this.

public string EmployeeName
{
   get
   {
      if (SelectedItem != null && SelectedItem.Invoice != null && SelectedItem.Invoice.Employee != null && SelectedItem.Invoice.Employee.Name != null)
      {
         return SelectedItem.Invoice.Employee.Name.ToString();
      }
      else
      {
         return string.Empty;
      }
   }
}

The requirements code is cluttered in null checks, since you don’t want the user to get NullReferenceExceptions when no invoice is selected or the selected invoice does not have an employee yet and so on. If you want to change the code to not use the Employee property anymore but to use the Sender property, make sure to change the two null checks as well. Not very DRY. Disadvantage of the above code is that the actual requirement is hidden in safeguard-code. There are multiple layers of abstraction and much code to maintain. And this is just a simple example. What would you have had to do if the sample had used methods with side effects instead of properties? Sure, CQRS but lets be honest. In order to not invoke a method twice, local variables are needed and your IF with a few conditions very quickly turns into a bloated mess. Good luck with cyclomatic complexity (have you heard about the C.R.A.P. metric?).

I don’t want to write all that safeguard-code since it blurs the view on what was originally required and makes it difficult to see why the code was written in the first place. I just want to write what the requirement is.

public string EmployeeName
{
   get
   {
      return SelectedItem.Invoice.Employee.Name.ToString();
   }
}

Yes, that would not work. In C#6 we could write it like this.

public string EmployeeName
{
   get
   {
      return SelectedItem?.Invoice?.Employee?.Name?.ToString();
   }
}

But what if a system is stuck on C#4 or C#5? Result.OrDefault lets you write the requirement like this.

public string EmployeeName
{
   get
   {
      return Result.OrDefault(() => SelectedItem.Invoice.Employee.Name.ToString());
   }
}

Result.OrDefault uses reflection to invoke one step at a time, checks for null and invokes the next step only if the result of the current step is not null (it only takes twice as long as with IFs for null checks). It allows property access, field access and method calls to be chained. Most important to me, it offers a much cleaner syntax since the focus is on the requirement and not on low level safeguard-code.

Unterstriche erhöhen die Lesbarkeit

Unterstriche in Testklassennamen und Testmethodennamen optimieren unterbewusste Augenbewegungen, entlasten damit die Augen und ermöglichen schnellere Erfassung der Zusammenhänge!

Der Mensch liest nicht buchstabenweise, sondern erfasst Wortbilder oder Teile davon nach spontanen, willkürlichen Bewegungen des Auges, den Sakkaden. Das Auge springt also von einem Zielpunkt zum Nächsten. Das sind die Sakkaden. Dann findet die Fixation statt, indem das Auge sich auf ein Wort fokussiert. Nur bei den Fixationen kommt es zu einer Informationsaufnahme. Fixationen nehmen rund 90 bis 95 Prozent der Gesamtlesezeit ein. Falls das Wort nicht erkannt wird oder irgendetwas dazwischen kommt, springt es automatisch wieder dahin zurück von wo es gesprungen ist. Das sind die Regressionen.

In “KadschfunHuAugenbewegungJfdskHundOhrHeIzr” existieren keine Wortzwischenräume sodass die Zielpunkte für die Sakkaden schwer zu finden ist. Dagegen in “Kadschfun Hu Augenbewegung Jfdsk Hund Ohr HeIzr” sind die Zielpunkte schneller zu finden, weil die Wortzwischenräume automatisch Zielpunkte für die Augen bilden. Ein optimaler Wortzwischenraum unterstützt Sakkaden und den Fixationsprozess. Es finden weniger Regressionen statt.

Testklassennamen oder Testmethodennamen bestehen häufig aus mehreren Eigenworten wie beispielsweise Klassennamen und Methodennamen. Ein gutes Beispiel dafür ist “InvoiceSubModuleVerschiedeneRvgStaendeTest“. Diesen Namen kann der menschliche Leser wesentlich langsamer lesen als “InvoiceSubModule VerschiedeneRvgStaende Test“.

Das liegt daran, dass hier die Augen das Wort InvoiceSubModule in der zweiten Schreibweise viel schneller nämlich unterbewusst erkennen können und weniger suchen müssen.

Wenn die Zielpunkte schwerer zu finden sind, muss das Auge mehr suchen, also hin und herspringen. Und je öfter das Auge springen muss, um einen Text zu erfassen, desto schneller ermüdet es. Außerdem wird der Lesefluss erheblich gestört und die Lesebereitschaft nimmt ab was dazu führt, dass ähnliche Texte fälschlicherweise als gleich angesehen werden.

Quellen

“Der menschliche Lesefluss findet in drei Phasen statt: Sakkaden, Regression und Fixation. Sakkaden sind spontane Blickbewegungen, die willkürlich und zielgerichtet ausgeführt werden, um bekannte Wortbilder oder Teilstücke davon zu identifizieren. Geübte Leser erfassen Texte nicht aus einzelnen Buchstaben, sondern erkennen an der Form des Wortbildes das einzelne Wort. Es genügt oft schon, wenn die Anfangs- und Endbuchstaben sowie die Buchstabenanzahl stimmen, um ein Wort zu erkennen – auch wenn im Wortinneren die Buchstaben einmal durcheinander geraten sind.
Das Auge springt von einem Zielpunkt zum nächsten und findet mühelos zurück, falls sich Ungereimtheiten auftun. Dieses Zurückspringen wird als Regression bezeichnet. Je schwieriger ein Text zu lesen ist, desto häufiger kommt es zum Hin- und Herspringen.
Sowohl die Sakkaden als auch die Regression dienen zunächst nur dem Erfassen des Textes; ein Sinnzusammenhang wird noch nicht erkannt. Dies geschieht erst in einer Fixation genannten Ruhephase, in der das Auge für einen kurzen Moment eine Ruheposition einnimmt, um dem Gehirn das Entschlüsseln der Botschaft zu ermöglichen. Diese kurzen Momente der Fixation nehmen jedoch beim Lesen mit bis zu 90% den überwiegenden Teil der gesamten Lesezeit ein.”

Aus <http://kadekmedien.com/2010/03/03/lesbarkeit-von-texten/ >

Ein optimaler Wortzwischenraum unterstützt den Fixationsprozess und dient somit derLesbarkeit einer Schriftsatzarbeit. […]
Bis in die 1970er Jahre wurde in der typographischen Literatur, z.B. in der von Jan Tschichold (1902–1974), die Formulierung »tadelloser Ausschluß« verwendet. Heute könnte man diese Begrifflichkeit als »idealer Wortzwischenraum« bezeichnen. […]
Wortzwischenräume werden in der relativen Maßeinheit Geviertgemessen.

Aus <http://www.typolexikon.de/w/wortzwischenraum.html >

Für den optimalen Wortzwischenraum gibt es die Faustformel 1/3 eines Gevierts […]
Starke Schwankungen des Wortzwischenraums behindern den Lesefluß. Das Auge erfaßt beim Lesen nicht Buchstaben und setzt sie zu Wörtern und Sätzen zusammen, es sieht Wortgebilde als bekannte Muster. Hierbei sind Unregelmäßigkeiten äußerst hinderlich. […]
Als optimal werden 50 bis 60 Zeichen pro Zeile für längere Lesetexte angesehen. Dies bringt im Blocksatz gute Wortzwischenräume.

Aus <http://edoc.hu-berlin.de/e_rzm/18/bynum/7.pdf >

Ohne Interpunktion und Wortzwischenräume wäre das schnelle und stille Lesen undenkbar. (Vgl. Fritzsche, S. 108.) […]
Die Wortzwischenräume erleichtern das schnelle und einfache Erfassen der Wortbilder bei längeren Zeilen und bieten eine Orientierung beim Zeilensprung des Auges. (Willberg/Forssman: Lesetypografie, S. 90.)

Aus <http://bmb.htwk-leipzig.de/fileadmin/fbmedien_bmp/downloads/Abschlussarbeiten/Zweisprachige_Mikrotypografie_Amelie_Solbrig_VH-02.pdf >

Argumente gegen Unterstriche

“Coding Styles gelten für Test-Code und Produktivcode” Was sagt Uncle Bob wirklich? Qualitätsansprüche oder Namenskonventionen? Es geht um die Qualität des Tests und wenn der Methodenname aussagekräftiger ist, desto besser. Ein Name wie “FinalizeDossierTest” ist zu allgemein und beschreibt nicht, was die Test-Methode testet, sondern nur, welche Produktivcode-Methode sie aufruft. “FinalizeDossierTest” trifft für beliebig viele Testszenarien zu, die hoffentlich nicht alle in der einen Test-Methode implementiert sind.

“Es ist besser wenn für Produktivcode-Methoden und Testmethoden gleiche Konventionen gelten, Qualität und so” eben nicht! Tests haben eine ganz andere Existenzberechtigung und damit auch andere Anforderungen als Produktivcode. Zum Beispiel die Verwendung des “Test”-Postfix (eigentlich sinnlos da Test-Attribut), des TestMethodAttribute und von Microsoft.VisualStudio.TestTools.UnitTesting.Assert ist nur in Tests sinnvoll. Auch sollten Tests nicht von anderen Tests abhängig sein. All diese “Konventionen” sind nur in Tests sinnvoll. Auch wenn die Testmethode die “gleichen Konventionen” einhält wie die anderen Methoden, wird die Qualität dadurch absolut nicht besser. Eine schlechte Testmethode bleibt schlecht. Einfachheit, Verständlichkeit und Vertrauenswürdigkeit macht eine Testmethode qualitativ besser. Nach Roy Osherove: Readable, Maintainable, Trustworthy http://artofunittesting.com/definition-of-a-unit-test/

“Unterstriche kommen in den Guidelines von .NET nicht vor” gemeint ist CA1707: Identifiers should not contain underscores (http://msdn.microsoft.com/en-us/library/ms182245.aspx) und General Naming Conventions (http://msdn.microsoft.com/en-us/library/ms229045.aspx) aber da geht es um API-Design, nicht um Test-Szenarien. Das wird auch dadurch deutlich, dass Jeff Prosise in “Framework Design Guidelines” (Seite 73) die Benutzung von Unterstrichen zur Kennzeichnung von privaten Feldern legitimiert. Auch Mike Fanning (Seite 377) legitimiert Unterstriche in Membern, die nicht extern sichtbar sind, wie beispielsweise Event Handlern, die nicht öffentlich sind. Auch Roy Osherove nutzt Unterstriche nicht in Wörtern, sondern zur Abgrenzung der drei Bereiche. Worum es in der Guidelines aber explizit geht ist “readability over brevity” (Lesbarkeit vor Kürze)

“Namen der Testmethoden werden zu lang” dann wird wahrscheinlich zu viel getestet. Durch kürzere Testmethodennamen werden die Tests auch nicht besser, sondern zwingen den Programmierer den Testcode vollständig zu lesen um zu verstehen, was eigentlich getestet wird (Zeit!). Robert C. Martin sagt: “The name of a function should correspond inversely to the size of its scope.” Wenn die Methode von vielen aufrufbar ist, sollte sie einen kurzen Name haben. Methoden, die von wenigen aufgerufen werden, können längere Namen haben. Testmethoden werden nur vom Testrunner aufgerufen und haben daher einen ganz kleinen Scope. Also sind längere Namen erlaubt.

“Prägnante Namen sind besser” bei Namen der Testmethoden geht es nicht um Prägnanz sondern Aussagekraft! DossierFinalizeTest() ist zwar prägnant aber sagt nur, welche Methode getestet wird -> schlecht. Die Testmethode sollte kurz sein und der Name aussagekräftig, nicht anders rum.

Das einzige was besser wird, ist die Professionalität des Teams, die es schafft, sich an eine Regel zu halten, um der Regel Willen. Das hat mit Qualität nichts zu tun.

Kompromiss

Wenn Ihre Coding Quidelines trotzdem Unterstriche verbieten, installieren Sie sich doch einfach meine Visual Studio Extension, die die Unterstriche in Test-Methodennamen einfach wieder anzeigt: https://github.com/halllo/MethodNameRepainting

Test Code with Single Responsibility Principle and Single Level Of Abstraction

The test code should depend on nothing, especially not the code under test. That can be achieved with an abstract base class with test methods. That makes sure the test code is on a high level of abstraction and closer to the domain model than to the code model. No more mock setups and other low level constructs mixed with the logic. A test adapter should connect test code with the implementation it should assert upon. The test adapter could be a derived class implementing the abstract members to invoke the code under test.
How do you see that the abstract test class is not dependent on the code under test? Usus.Net or some other static code analysis tool shows the type dependencies.
There are similarities to FIT here. Tests are loosely coupled from the implementation. The greatest advantage in my opinion is that the “test language” can be created independently from any implementation detail.

Example

public abstract class MultiplySpecification
{
	protected abstract int Multiply(int first, int second);

	[TestMethod]
	public void _1times2_equals_2()
	{
		Assert.AreEqual(2, Multiply(1, 2));
	}

	[TestMethod]
	public void _2times2_equals_2()
	{
		Assert.AreEqual(4, Multiply(2, 2));
	}
}

[TestClass]
public class MultiplyTestAdapter1 : MultiplySpecification
{
	protected override int Multiply(int first, int second)
	{
		return new CodeUnderTest().Multiply1(first, second);
	}
}

[TestClass]
public class MultiplyTestAdapter2 : MultiplySpecification
{
	protected override int Multiply(int first, int second)
	{
		return CodeUnderTest.Multiply2(first, second);
	}
}

public class CodeUnderTest
{
	public int Multiply1(int first, int second)
	{
		return first * second;
	}

	public static int Multiply2(int first, int second)
	{
		return first * second;
	}
}

CleanCode & Software Craftsmanship

CleanCode ist für mich persönlich, damit mein Code gut wird. CleanCode ist es nicht würdig darüber zu diskutieren oder zu verteidigen. Ich gewinne nichts, wenn ich versuche meinen Pairings Partner zu überzeugen: a men convinced against his will is of the same opinion still.
Ich verliere nur Zeit, Nerven, Motivation. Mein CleanCode ist wichtig. CleanCode anderer ist unwichtig. Wenn mein Pairings Partner zu meinem Code einen “Vorschlag” hat, prüfe ich diesen auf Korrektheit, nicht auf CleanCode. Er darf den Vorschlag dann implementieren. Ich sage nichts, mache mir aber bewusst, welche Nachteile der Vorschlag in Bezug auf CleanCode hat. Als Konsequenz versuche ich öfter mit Partnern zu pairen, die CleanCode machen und weniger mit welchen die nicht. Um mich und mein CleanCode zu schützen. CleanCode und Software Craftsmanship ist MEIN Handwerk!

Master, Usus.NET and other projects

It has been a long time since I published my last blog post. A little over two years actually. Back then I was writing about the small Visual Studio extensions that I created in order to improve my productivity. Now, two years later, I just finished the biggest Visual Studio extensibility project I have ever worked on. I worked on this project while writing my masters thesis about static code analysis, code metrics and clean code at andrena objects AG (andrena.de). Before I come to describing what it is, let me express my satisfaction about being done studying. I obtained my Master Of Science in Computer Science degree last Friday.

When I was done with my bachelor, I wrote that a degree does not really proof anything except that one spent some dedicated time studying complex topics and coding experimental software in daylong labs. I am glad I spent that time. I learned a lot but the most important stuff I learned I learned outside the classroom. Writing my masters thesis at andrena was a great opportunity to learn from great people like Fahd Al-Fatish and Robert C. Martin. Unfortunately andrena is mainly a Java shop, so I did not find many C# projects there where I could use my over 7 years of experience in programming for the .NET framework. When I submitted my thesis I had one month of free time until I started my first full time job on 1st October at STP Informationstechnologie AG (stp-online.de).

In that one month I thought I would have time to write this blog post but time was never really there. It is not here now either, but I am forcefully taking these minutes. Scott Hanselman left me with an adjusted view on how to approach things (watch his very interesting talk at vimeo.com/39020426). There have been a few projects of mine that I really want to introduce here. Since I don’t know whether I will have the time to pursue any further projects during my spare time, I at least want to be done with the others waiting in the back of my mind to be written about.

I also want to show some code snippets. In my previous posts those snippets always looked ugly so I went and looked for a better solution. Due to the fact that I don’t host my own content management system but use the free wordpress hosted thing, I do not find much use in source code formatting plugins. What I found was this Code Highlighter at quickhighlighter.com/index.php?lng=csharp. Unfortunately Windows Live Writer decided it can no longer post to my wordpress blog. So I had to copy this text over into the web interface. All the formatting of the code snippets got lost and I did not want to format it all by hand. So the code in this post looks even uglier than in the previous posts but I just don’t care anymore. You can distinguish the code from the rest based on the line numbers.

Usus.NET

My masters thesis was about static code analysis and how this can be utilized to improve clean code. I created a Visual Studio extension which can perform a static code analysis and calculate metrics and quality indicators on every build. It shows problematic sites in the code and calculates code metrics and the andrena software quality index. I also engineered a dedicated clean code metric based on the statistical distribution of the metrics which I call The Naujoks Coefficient (lambda of the geometric distribution). This metric can be applied to any metric histogram and is based on intentions of Robert C. Martins book Clean Code.

The name of the extension is Usus.NET and it is entirely open source. I also take pull requests. You can find the source and everything related (including my masters thesis) at github.com/usus/Usus.NET. If you don’t want to get the code and compile it yourself, you find the VSIX file for directly installing onto Visual Studio on my website at mnsdc.de/programme/vsix_programme.htm. But this is not the most recent version. I compiled it when I finished my masters thesis. Any later check-ins to the repository at github are not included.

The screenshot below shows how the information is visualized in Visual Studio.

But Usus.NET also comes as a simple library which lets you integrate its functionality into your own applications. Here is the code that analyzes an assembly or the executing assembly itself.

  1. //var metrics = Analyze.PortableExecutables(assemblyToAnalyze);
  2. var metrics = Analyze.Me();
  3. foreach (var method in metrics.Methods)
  4. {
  5.     Console.WriteLine(“Signature: ” + method.Signature);
  6.     Console.WriteLine(“CC: ” + method.CyclomaticComplexity);
  7. }

The quality indicators can be queried like this.

  1. RatedMetrics rated = metrics.Rate();
  2. double acd = rated.AverageComponentDependency;
  3. int cyclicNamespaces = rated.NamespacesWithCyclicDependencies;

The problematic sites in the code, which Usus.NET refers to as Hotspots, can be determined like shown below.

  1. MetricsHotspots hotspots = metrics.Hotspots();
  2. var complicatedMethods = hotspots.OfCyclomaticComplexity();
  3. var bigClasses = hotspots.OfClassSizeOver(10);

Usus.NET has opinionated default thresholds for any calculation. Those could also be adjusted at runtime, but I don’t recommend that. There has been much consideration gone into finding those thresholds. If you would like to know more about this, please read my master thesis at github.com/usus/Usus.NET/tree/master/Documentation.

But with all these metrics and quality indicators, I believe that the community needs to have an adjusted mindset regarding interpretation of code metrics. A method with a high cyclomatic complexity (CC) is not listed because of its high CC but because it is complicated. The developer should not try to get it off the list but to make it more manageable and less complicated. If you are not sure what the difference between complex and complicated is, take a look at the great image at Erwin van der Koogh’s blog.

Usus.NET is far from being done. I am done with my masters thesis and thus with actively developing it. I will be adjusting it when time allows it, but I would like the community to have a look at it, take it on, improve it and make it awesome.

LangLight

Before I even started working on Usus.NET I actually had some free time. I was actively creating many Windows Phone 7 apps. A list of all those apps can be found on my website at mnsdc.de/wp/. Anyway, wanted my apps to be in both German and English at the same time. I don’t like the approach that .NET is taking with resource files, so I tried to create my own very lightweight solution of internationalization. LangLight is a Visual Studio extension that enables simple translations for WPF, Silverlight and Windows Phone 7-7.5. It uses XML driven code generation and creates bindable properties.

You need to create a simple XML file that contains the translation information like below.

langlight-s1
If you click on the “generate code file” button, LangLight will create a C# source code file for you. Then you can bind to any of these translations using XAML like so.

  1. Content=”{Binding merken.Translation, Source={StaticResource translations}}”
  2. Content=”{Binding hierWeiterlesen.Translation, Source={StaticResource translations}}”
  3. Content=”{Binding versenden.Translation, Source={StaticResource translations}}”

Or use it directly in code.

  1. App.Helper.AppBarMenu(this, 2).Text = LangLight.i18n1Translations.Instance.nächstesKapitel.Translation;
  2. App.Helper.AppBarMenu(this, 1).Text = LangLight.i18n1Translations.Instance.vorherigesKapitel.Translation;

It allows for language switches without restarting the application and provides a very easy to understand API. You can change the language with a simple method call.

  1. LangLight.i18n1Translations.Instance.TranslateToEnglish();
  2. LangLight.i18n1Translations.Instance.TranslateToDeutsch();

I also created a screencast where I show off this basic use case screencast.com/t/I3iejxYnA. Listening to it myself is still very funny. Anyway, you can download the extension on the Visual Studio gallery at visualstudiogallery.msdn.microsoft.com/7b952a77-3207-4180-a350-c9d4fb852846. Two of my other extensions are there too: MethodLog and StatePatternModeler. But I already introduced them in the previous blog posts. All my productivity tools can be found on my German website as well mnsdc.de/programme/vsix_programme.htm.

MKinect

After I wrote my bachelors thesis at CAS Software AG (cas.de), I worked on the PrimeSense SDK for Kinect. The Kinect for Windows SDK was not released then but the Kinect was pretty much hyping back then. At CAS, I created a library that enables the Kinect to be used very easily with WPF. Because CAS could not see any direct advantage of integrating natural user interfaces in their applications, I open sourced that library and put its code on github at github.com/halllo/MKinect. The library is called MKinect and comes with many helper classes, that make it easy to add special gestures to any .NET application, especially when using WPF. I also created a showroom app in order to show off some of its functionality. The video of it can be viewed at screencast.com/t/wy6ndBGvS.

For example, if I wanted to track body parts as they are projected onto a simple Canvas, I need to declare a special Canvas-wrapping TrackingEllipseCanvas with two boxes that represent button-like areas.

  1. <hcanvas:TrackingEllipseCanvas x:Name=”tracker_canvas”>
  2.     <Rectangle Width=”200″ Height=”100″ Canvas.Left=”84″ Canvas.Top=”200″
  3.        hcanvas:HighlightCanvasItemContext.Handler=”{Binding LeftColorBox}”/>
  4.     <Rectangle Width=”200″ Height=”100″ Canvas.Left=”490″ Canvas.Top=”200″
  5.        hcanvas:HighlightCanvasItemContext.Handler=”{Binding RightColorBox}”/>
  6. </hcanvas:TrackingEllipseCanvas>

Then I need to specify what body parts the Kinect should keep track of.

  1. head = GenericActionFactory.Create<MoveableBodyPart>(this.kinect, s => s.Head);
  2. lHand = GenericActionFactory.Create<MoveableBodyPart>(this.kinect, s => s.LeftHand);
  3. rHand = GenericActionFactory.Create<MoveableBodyPart>(this.kinect, s => s.RightHand);
  4. lShoulder = GenericActionFactory.Create<MoveableBodyPart>(this.kinect, s => s.LeftShoulder);
  5. rShoulder = GenericActionFactory.Create<MoveableBodyPart>(this.kinect, s => s.RightShoulder);
  6. this.tracker_canvas.StartTracking(head, lHand, rHand, lShoulder, rShoulder);

That is all I need to do if I just want to have beach balls floating around which represent the associated body parts. Any additional action can be set up using a very fluent interface.

  1. When.The(leftHand).Enters(LeftColorBox).Do(() =>
                                               RectColor1 = new SolidColorBrush(Colors.Red));
  2. When.The(leftHand).Leaves(LeftColorBox).Do(() =>
                                               RectColor1 = new SolidColorBrush(Colors.Gray));
  3. When.The(rightHand).Enters(LeftColorBox).Do(() =>
                                                RectColor1 = new SolidColorBrush(Colors.Green));
  4. When.The(rightHand).Leaves(LeftColorBox).Do(() =>
                                               RectColor1 = new SolidColorBrush(Colors.Gray));
  5. When.The(rightHand).Enters(RightColorBox).Do(() =>
                                               RectColor2 = new SolidColorBrush(Colors.Blue));
  6. When.The(rightHand).Leaves(RightColorBox).Do(() =>
                                                RectColor2 = new SolidColorBrush(Colors.Gray));

Can it get any easier than that? All this code is freely available but so far requires the PrimeSense NITE SDK.

MReplace

Quite recently I came across a great CodeProject article by Ziad Elmalki codeproject.com/Articles/37549/CLR-Injection-Runtime-Method-Replacer. He was experiencing with the method table and JITing. I turned what he found out into a simple isolation framework. Using a very lightweight API, MReplace allows to replace any non-framework method and property at runtime, without any profiler. Full fledged Frameworks like Typemock Isolator, Telerik JustMock and Microsoft Fakes use a profiler to intercept method calls at runtime. MReplace does not. It goes for the method table and substitutes the pointer to any method with a different pointer. Before I show you how to use it, let me tell you that it is open source and can be found on my github at github.com/halllo/MReplace. But lets take a look at a simple test method now.

  1. [TestMethod]
  2. public void Replace_StaticMethod()
  3. {
  4.     Assert.AreEqual(2, ClassUnderTest2.StaticMethod2());
  5.    using (Replace.Method(() => ClassUnderTest2.StaticMethod2())
                                     .With(() => ClassUnderTest1.StaticMethod1()))
  6.    {
  7.       Assert.AreEqual(1, ClassUnderTest2.StaticMethod2());
  8.    }
  9.    Assert.AreEqual(2, ClassUnderTest2.StaticMethod2());
  10. }

In the using block, ClassUnderTest2.StaticMethod2() returns something else than outside. MReplace lets you break dependencies by changing method implementations at runtime, without needing anything to be attached to the CLR process. There is one small draw back though: MReplacedoes not work if the application is started in debug mode. But debugging tests is bad practice anyway since TDD should lead to non-debugging development activity.

MStrings

The last library I want to introduce in this blog post is about screen scraping. It is part of my “getting started faster with any Windows Phone 7 app”-framework called SilverlightRun, which is on github at github.com/halllo/SilverlightRun. But since I already needed it in other environments as well, I moved it into its own reusable package. MStrings is also on github at github.com/halllo/MStrings and supports easy string manipulation. I use it very heavily for parsing webpages in The Mentalist Episodes app (windowsphone.com/en-us/store/app/the-mentalist-episodes/cd58bb75-dea0-4f7d-b7ad-d5e996a9ff08). Since there is not much to it. It lets you extract substrings from bigger strings, like shown in the code below.

  1. string result = ContentScraper.For(s)
  2.     .StartingAt(“<“).UntilLast(“>”)
  3.    .Replace(“<“, “”).Replace(“>”, “”)
  4.    .Replace(“\r”, “”).Replace(“\n”, “”)
  5.    .Replace(“&quot;”, “\””)
  6.    .Replace(“&nbsp;”, “”);

I find it very useful for extracting HTML tags. Maybe I will even turn this into a NuGet package.


Ok, the psychic weight of this stuff is now off my mind. I cannot believe it took me over a month to finish writing this blog post. But hopefully you will find something of it useful and consider using it in any of your projects. Most of my stuff is on github.com/halllo, so please don’t hesitate to send me pull requests. In case you do not already, please follow me on twitter at twitter.com/halllo and visit my website njks.de.

Take care

Manuel Naujoks