Called out on the Switch Statement

I was going over TDD with a developer and made a statement that I avoid using switch statements. (I may have used stronger language like "never use", can't remember.)  Then a few days later, I was pair programming with the same developer and I used a switch statement.  The developer, frustrated and confused, called me out on it.  

We were working on parsing XML sax style using xmlreader and writer.  I was also copy and pasting code from the sample as a first pass to quickly get my tests to pass.  If I needed to change... that is what refactoring is for.

While I was chopping wood for the fireplace, I was reflecting on this issue and I came up with the following.  On more than one occasion, I have had to refactor switch statements to either if else statements or, in some cases, a full blown rules engine.

I have nothing against the switch statement, other than it does not leave me much room for refactoring.  The "if" statement is reduced to a boolean in both the switch and if-else.  But in the switch statement one operator immutable throughout the evaluation set.  In contrast the "if-else" allows both sides of the equation to change at each decision point.

The XML example, using switch was fine.  The problem domain is fixed and backed by well established enumerations against a very mature standard.  When I am working out something new on my own, where both sides could change, I stick with the if statement or something else that is more flexible.

TDD and Static Methods

Static methods present a problem in TDD. Interfaces do not support static methods. This can put a damper on fluent interfaces, unless the fluent interface is first developed in a TDD-ish manner and under test, then a fluent interface is put on top of the functionality.  This is usually how it is done anyway.

Especially in TDD avoid static methods unless you have a "good" reason to use them.  Trying to reduce two lines of code down to one for invoking a class, is not a good reason (in object oriented programming.)

NorfolkJs

The very first NorfolkJs meetup tonight. Great group, even had a pair of Google glasses starring at me.

Kevin had good suggestion, next time show filters on repeat.

Also note to self, if it has been a month since doing ng-class. .. brush up before presentation lol.

Presentation was on angularjs.

Went over data binding, controllers, ng-filter, ng-class, karma test runner, jasmine, testing, and a plug for egghead.io for training.

TDD simple definition

Stating that TDD is just red, green, refactor, is like stating all you need to know to perform an appendectomy is make a cut and remove the appendix.

MOQ and out parameters

MOQ does not support out or ref parameters.  This bring up the debate about how testing tools can limit the developers creativity.  In the end testing is important.  There are other ways to accomplish the same goal.  The out parameter is nice but, testing is nicer.

public bool hasPermissions(string context, out List<string> allPermissions);

restructured to 

public bool hasPermissions(string context, List<string> allPermissions);

Not much of a change, but I do blow out all the data passed in.

Amazon Tech bookstore

Just saw that Amazon.com has a new tech book store.  Dino Esposito was right on the front page.  Cool!

Reading Code

I was asked to make a list of C# apps to learn coding style from. There are many good ones out there.  These are the first ones that came to mind this early in the morning.

Any app that is TDD is probably a good one to learn from.  TDD supports good development style.

https://github.com/ravendb/ravendb

https://github.com/markrendle/Simple.Data

Not C# but still good.
https://github.com/angular/angular.js