9.24.2009

The slippery slope of "var"

The var keyword has been a rather controversial addition to the C# language. Many developers initially fear it, getting lost in demos that use it. Eventually, they come to understand it as something "lazy" programmers would use and often dismiss it. I've gone through these stages. I even remember my blood boiling when I saw resharper, out of the box, suggest to use it! I never really understood it as anything more than implicit typing.

Recently, I decided that I should learn new concepts with new languages instead of just trying to learn and do examples in the same old. Why not kill two birds with one stone! I've been exploring a lot of interpreted languages (functional and imperative), focusing on Scheme (LISP) and python. I've had a great joy reading and conceptualizing new things in these language.

Studying new concepts and applying them with dynamic languages has made me notice, more than ever, all the boiler plate type code to get anything done in C#. After a weekend of hacking in python, I find myself skipping type declarations in C# only to get compiler errors :(. The simplicity of

names = ('Bob', 'John')
in python is doubled in C# to
List<string> names = new List<string>{ "Bob", "John" };
without any added value!

I have been struggling to find ways to bring this simplicity to C#, short of switching to python altogether :). My favorite way is to cut some of the crap and go with
var names = new List<string>{ "Bob", "John" };
. No loss of information and some added clarity! However, the use of var is often frowned upon as if it were unprofessional, my peers reading my latest code only to comment on my "abuse" of it!

What I was missing is the next step in the progression of understanding var. I was starting to realize that it adds clarity through readability! No longer do I have to scan through a bunch of type verbiage in a variable declaration to find the name, let alone the content. Readability alone wasn't convincing my critics so I pondered on the topic some more in regards to another set of concepts I have been working to grasp, DDD.

In studying DDD (Domain Driven Design) I detected a sense of deja vu. The core concepts, of creating a ubiquitous language and model that permeates code, was resonating all the way down to the level of variables. If a variable represents a list of employee names, it should be labeled employeeNames. If we cram that much intent and meaning into our variable names, why do we even care what primitive or compound type is used?

employeeNames might be implemented as a List<string> in C# or a simple list in python. However, when all is said and done, employeeNames is neither a List<string> in C# nor a list in python. Thinking about it as such adds no value, just translation overhead. employeeNames is simply a variable to store employee names, it's type is employeeNames! The name implies this directly. It describes a kind of name, employee, and it's plural, clearly a collection or set of names. The same would apply for a variable to represent age, even if implemented as an integer, it's not an integer, it is an age!

I think this is the answer to help convince people that using var is actually a good thing. Especially when writing unit tests where readability is a primary concern. I would even go so far as to suggest using it anywhere when declaring a variable. The only argument I have heard against this, thus far, is that this will lead to ambiguity. But wait a minute, I think the opposite is true! Static typing leaves room for intention to be left in the type itself. Because of this, developers get sloppy with variable names. When developers don't have a type to prefix a variable, they typically put more intention into the name, for their own sanity!

I would be more inclined to believe I would run across
List<string> employees = new List<string>();
in C# than
employees = ('Bob', 'John')
in python. This example requires knowledge that employees is implemented as a list of strings for someone to extrapolate that employees holds names and not ages or something else. However, with a list of strings, this may just be a guess! It could be a list of their emails or maybe home addresses! I know I've seen this in the past and I know I've done it myself. This added translation only decreases the maintainability of the code.

So the next evolution, in the slope of understanding and using var will be understanding it as a tool of readability and to help avoid leaving intention in types. This adds a layer of linguistic abstraction that hides the implementation of our variable's type and makes it more flexible.

I think the last evolution with var, will be to help developers get more familiar with the ideas behind dynamic typing. Implicit typing is like a step in the direction of dynamic typing. The last thing to do, seems to be to drop the use of var at all. It's simply linguistic boilerplate to developers (even if it serves a purpose to the C# evaluator).

So get your var on, don't be ashamed!

9.6.2009

Weighted Average in python

  def WeightedAverage(items, value, weight):
    numerator = sum(value(i) * weight(i) for i in items)
    divisor =  sum(weight(i) for i in items)
    return (numerator / divisor) if divisor != 0 else None
8.21.2009

My cool code snippet

I submitted this to the Resharper cool code snippet competition and thought I would share it with everyone else, including why it’s cool!

[Test]
public void $METHOD$$SCENARIO$$EXPECTATION$()
{
  $END$
}
I’ve been doing a lot of TDD lately and I am constantly writing new tests. So my number one snippet is one that creates a simple test. I’ve tweaked this template a lot, it started out with a simple test template with only one editable occurance for a name. In “The Art of Unit Testing,” Roy Osherove talks about test readability which starts with the test name itself. He suggests putting the test method name together with three components. First, name the method under test (the Act in AAA), that way related tests for the same method are easy to identify (and actually R# sorts test fixture test methods by name so this is even more useful with Code Cleanup :) ). Second, name it with a scenario, what is unique about the given context of the test (known as the Arrange in AAA). Finally, include the outcome of the test, the expectation (Assert in AAA). This way you know all of what will go into the test before you write it!

I gave his naming scheme a try and found out it offers a pit of success. If you cannot name these three parts then your test likely won’t be readable. Anyone should know what a test does without reading it, like with any method, it should be intention revealing! Without identifying a scenario explicitly, it may be blurred in several lines of setup (Arrange). Having the scenario in the name makes it explicit and makes me keep it simple (I hate long method names). The test may have too many expectations, again, I hate long method names so if I find myself putting multiple expectations in the name I will quickly realize I need to move the other expectations to new tests (SRP with testing)!

The same day I tried using this test method naming convention, was the same day I created this test snippet and have kept it ever since. Every time I write a test, I am very explicit and careful, which is very important with TDD, not to take on too much with any one test!

This snippet is awesome, not because of the code it creates, but because it sets myself up for success every time I use it, like having Uncle Bob Martin watching over my shoulder :)

8.5.2009

Outlook 2010 + Google Cal Sync hack

So yeah Google Cal Sync doesn’t work with Outlook 2010 Preview, but I found a way to get it to jive.

I edited Outlook.exe in C:\Program Files\Microsoft Office\Office14 using Notepad++ with the Hex-Editor plugin. At assembly location 0x000c09b2, I changed the value to 0x32, in the ascii dump. It originally read (14.0.0 and now reads (12.0.0

Good luck, I have no idea what this might break, I hope it is just the outlook version that the add in manager reports to add ins :). I have successfully synced events to and from my GCal!

-Wes

8.4.2009

Ling2Sql custom mapping gotcha with entity base class

If you are doing custom Linq to Sql mappings, it currently doesn’t support having your own base Entity class that you extend all your entities from. I found out the hard way through painful debugging. However, it seems if you do this with the version of .net 3.5 sp1 on the Win 7 RC it will work, so this may not be a bug forever!