Standard is Better than Better

Neal Ford wrote some interesting things about naming conventions: Eating Sacred Hamburger. And even though I agree with everything he says, I think he draws the wrong conclusions.

He first argues the relative merits of various naming conventions, preferring ruby_case to CamelCase, especially for very_long_and_drawn_out_method_names. It think he hits it right on the button, though I personally prefer lisp-case for very-long-and-drawn-out-method-names, since it’s easier to type.

He also argues against Hungarian notation, which I agree is a blight upon all that is good and green. And the IInterface notation is also a little silly, but…

It’s convention. We should follow the convention.

Did I just say that? Giving up progress, and readable code, just to do it in the same way it’s always been done?

Well, yes. Remember in C++, when you were using STL sometimes and MFC sometimes? They used different naming conventions entirely. And you could never remember what goes with what. Intellisense helps with that some, but it’s still awkward. And what about reading the code? While it may be a little clumsy to read long names in camel case, it’s far better to have the formatting match. The overall codebase is more beautiful as a result.

So, I say: bring on the IInterfaces! At the end of the day, I don’t care how we name things as long as we name them the same way. Or, to quote my boss: “standard is better than better.”

(Maybe they got rid of Hungarian notation not because it sucks (which it does), but because they couldn’t get everybody to agree on it. A convention is only useful if everybody does it. And right now, in C# at least, everybody does do it. It’s great for an old C++ hacker like me. So please, don’t break it!)

Technorati Tags: , ,

Essential Windows debugging tools

I’m no Windows dev expert, but I’ve been doing it long enough to have collected a set of tools that go with me. They sit in a nice little rectangle on my desktop, and I also have a USB key to carry them with. Not all people know about them though, or maybe have seen them and haven’t learned to use them. I recommend at least familiarity with the following:

  1. OleView I do a lot of COM work. I try to make it go away, but it keeps coming back. As such, my first choice of debugging tool is good old oleview. Every time our install breaks because of some munged dependency, the first step is to fire up oleview and check that all needed objects are registered, and that they can all be instantiated. That last bit is non-obvious but very cool – when you expand an object in the list and it turns bold, the object is actually being instantiated. So just expanding each one you care about is a good smoke test.
  2. Filemon Everybody probably knows this one already, but it’s so important that I can’t leave it out. If you haven’t used it, do yourself a favor and get familiar. It can be used for any program running on windows, so it’s good even for you Java folks. My strategy with Filemon is usually to first figure out a concise way to reproduce the problem, then do a specific session to see what’s happening. I usually forego the filters (remember the COM I’m running from? Lots of out-of-process servers there.) and just start/stop event logging at the right times.
  3. .NET Reflector Ah, what would we do without Lutz Roeder? I’ve used this to read my own (decompiled) code while working through a bug on a test machine. Saved me some walking back and forth at least, plus I felt like such an incredible badass doing it. It’s also good for determining that the localizer sent you back an assembly built with .NET 2.0, when you very clearly asked for 1.1. (A co-worker’s find, not my own)
  4. Spy++ Are you noticing a theme here? All the old tools that let us observe the bowels of the system are still useful. Sometimes you just want to watch the messages fly by, and Spy++ is still the way to do it. ManagedSpy may be worth a look too.

As mentioned above, what I find compelling and useful about these tools is that they take a step away from what your software is supposed to do (that’s what the source is for) and let you know what it’s actually doing. There’s an entire class of subtle bugs that such insight enables you to diagnose – the first two tools have saved my ass on multiple occasions.

Technorati Tags: , , ,

Easy C# Memoization

I called it MagicCache at first, thinking I’d come up with something new and cool! But, as usual, I’d actually just forgotten the name.

Memoization is a useful but intrusive technique. It’s the kind of thing that I want to be able to wield around my code and put it where I need it, almost as a configuration-time parameter. So I’m not quite satisfied with just writing the code myself each time I need it. This is a perfect case for AOP.

The approach I took was not to use an existing AOP framework, since I think that would freak my coworkers out a little, but rather to do my own simple system. It uses the fantastic DynamicProxy (as do all C# AOP systems I know of) to inject code, and I use a custom attribute to mark the invocations I care about. The result is quite pleasant to work with:

virtual int Sum(int a, int b)
    return a+b;

Or, in more complicated cases:

virtual object BuildObject(string paramA, int paramB)

I like this particular method because the caching policy is nicely separated from the actual logic, but has enough proximity to see what’s going on. And I don’t have to write the caching code again and again, which means I’m free to enhance the general caching algorithm.

Of course it’s not quite as easy as all that. Memoized methods must be virtual, for DynamicProxy to be able to intercept the invocation, and the object in question must be wrapped in a proxy object. In my case I wrapped it all up in a single method call, Memoizer.CreateProxy(obj). For objects that are already built in a factory this is not problem at all, but sometimes it’s kind of inconvenient.

I’ve also added the ability to treat returned strings as paths to files which are deleted when they are removed from the cache, though I haven’t thought through it well enough to be generally useful.

Technorati Tags: , ,