Today i started working on the biggest project in my company. I’ve worked at it again in the past. It’s the best expression of legacy code. For me it’s a total blast. Bad code all around. And I love to swim in it.

I really like using R#’s “sharp” edge to slice through it. “Always true” expression? Redundant else? Unnecessary delegate construction? Bad format? Unused variable?

It’s quite amazing how much R# improved my and my colleagues code. When looking at the code of the past it’s incredible how dirty and filled with namespaces the code is.  This has turned me into a code cleanup junky.

I also like to delete as much code as i can. I still don’t understand how a region could be of any help. Playing hide and seek with functionality? I especially enjoy deleting entire projects. It’s the “minor optimizations also count” side of me.

But lately this barely satisfies me. Now, to get really high i need at least a concept extracted into another class.

So given a currency the application layer would return some other fields. Very nice. But what about an invalid currency. There is a cache in which available currencies are stored. If an invalid currency is provided the returned Currency type of object would be null.

Now the implicit part. Given a null currency the application layer would compute null fields. And that is excellent because that is one of the requirements. If the user enters an invalid currency the depending fields should be cleared. But is this good? We don’t have redundancy. But because of this you can’t really express the requirement in a unit test. That’s because given an invalid currency someone else really decides to clean the fields (by returning the null values). So the code looks really nice

   1:  public void OnCurrencyChanged(string currencyString)

   2:  {

   3:      Currency currency = currencyCache.GetFor(currencyString);

   4:      InteresetAmount amnt = applicationLayer.GetInteresetFor(currency);

   5:      view.UpdateInterestAmountTo(amnt);

   6:  }

Simple and clean, right?

But there is another issue with this, one more insidious. It is assumed that something happens in the application layer. I’m not sure if this is right though. I am counting on a HashTable to return a null object if the given key is not found in the dictionary, am i not? I think this is not really the same case. First of all we don’t have access to the code. It is framework code. MS would not change that code very soon because it would be a breaking change.

But some, given the right circumstances, might modify the application layer, so having a null Currency it would return a default interest amount. It sure sounds silly, but I’ve seen worse stuff. And right now I’ve just introduced a bug in the codebase. And it’s quite a nasty one. Tester might not find.

The latter, the explicit implementation translates to checking for null the currencyCache retrieved currency. If null explicitly clean the fields like:

public void OnCurrencyChanged(string currencyString)

{

    Currency currency = currencyCache.GetFor(currencyString);

    if(currency==null)

    {

        CleanInterestAmount();

        return;

    }

    InteresetAmount amnt = applicationLayer.GetInteresetFor(currency);

    view.UpdateInterestAmountTo(amnt);

}

I find this to be cleaner. Even if redundant in some way. And the test is also clear and well placed:

[TestFixture]

public class When_user_enters_invalid_currency

{

    [Test]

    public void Should_clear_interest_amount()

    {

        var currencyString = "Invalid Currency";

        currencyCache.Stub(cc => cc.GetFor(currencyString)).Return(null);

        var sut = CreateSut();

        sut.OnCurrencyChanged(currencyString);

        view.AssertWasCalled(view=> view.UpdateInterestAmountTo(null));

    }

}

This is also the opinion of some stackoverflow folks.

Of course nothing comes for free. We get the nice test, and the explicit, revealing code. But we also get redundancy.

In conclusion, some redundancy might be good for your code after all?

It is pretty usual for a Novice/Advanced Beginner to look at patterns as recipes. I’m not saying that I might be Competent or even Proficient but under internal and most notably external forces i started to look at patterns as better/best practices rather than mandatory recipes.

I find myself holding my point of view and some colleagues quoting Martin Fowler when discussing MVP. Of course I’ve read myself articles and books written by the great man. But from time to time you have to make your own road.

To the subject. Yesterday we were discussing a particular situation. We are trying to maintain presentation related logic in the Model (we are using Passive View). We have a Currency field in the View and dependent upon the Currency field there are two other fields Interest Method and Interest Amount. So when the user modifies the Currency the other two fields get computed in the Model and reapplied to the View. So in the Presenter  we have something like:

   1:  public class Presenter

   2:  {

   3:      public void OnCurrencyChanged()

   4:      {

   5:          Model.UpdateCurrencyTo(View.Currency);

   6:  

   7:          View.InterestMethod = Model.InterestMethod;

   8:          View.InterestAmount = Model.InterestAmount;

   9:      }

  10:  ....

  11:  ....

  12:  }

A big part of my morning ritual is getting the latest build, viewing the changes and installing it.

Just to be a bit closer to the edge I’ve created a pretty big list of R# live templates. Some I feel are outdated, and my laziness keeps me from bringing them up to date. But either way, some of you might find them helpful.

Some of them are quite simple like “dt”, which stands for “DateTime” and some are more complex like “tf” which stands for test fixture which generates a class marked with [TestFixture] that derives from the class in which we are. The classes name starts with “When_” and the test method inside of the test fixture starts with “Should_”. I’ve created all this templates at the time of my obsession with Context/Specification style of testing. I’m still at the Advanced Beginner level i like to think.

Also it is important to note that the live templates are created as “Mounted Storage” in R#.

Live Template

I can’t remember where i got the first version of it, because it sure was not my idea. But as I’m “always” trying to improve my speed of typing, and really liked the idea of vim but didn’t quite made it work with R#, I’ve created this script. Well, what it does? It does an amazing thing .

Jean-Paul Boodhoo’s posted script used the CapsLock key as the escape key which in conjunction with other keys allows him to stay on home row like this:

CAPS + E – Esc
CAPS + J – Down Arrow
CAPS + K – Up Arrow
CAPS + L – Right Arrow
CAPS + H – Left Arrow
CAPS + F – Cycle forward through task switcher apps
CAPS + D – Cycle backward through task switcher apps

Mine goes a bit further I think. It uses the left Alt key as the “escape key”. I know, it might not be the best option, but I found it is the one that I most easily can combine with other keys, on either side of the keyboard, but especially the right side. The right Alt key works the “old” way.

But I expanded it further like: Alt + Y, O are remapped to Ctrl+Left and Ctrl+Right… Alt+0 to F12, left Ctrl+0 to R# Find Results, Alt+Shift+0 to Alt+Shift+F12 (R# Go to usages of symbol) and many others…

StayOnHomeRow.ahk