Code beauty 3

It’s pretty clear that there are two basic kinds of developers; those that write code only to get the job done, and those that write code which in addition to getting the job done also looks good. I’m definitely part of the latter group and I have to say that sometimes I get frustrated when working with developers of the former conviction.

I was just reviewing some code written in a project I haven’t been involved in much, and found a set of very commonly used classes that lie in a namespace that is misspelled. I realize this doesn’t matter. I mean, the code does exactly what it’s supposed to do and the misspelling is so simple that everyone understands what it was meant to be called. But c’mon! Correcting the mistake would take about 2 minutes thanks to the refactoring functionality in Visual Studio.

Now to the difficult question… Should I mention it in my review?

3 thoughts on “Code beauty

  1. Richard Edwards May 16,2007 19:16

    Mention it! It will make the code easier to document, or nudge it closer to being self-documenting. Typos in the codebase can be a bigger headache for documenters, who usually have to describe the code out of context. Even if the code you reviewed doesn’t need to be documented for external consumption, it will be helpful to raise awareness of the problem.
    And, while I’m here… thanks for your blog! I’ve been enjoying it for several months.

  2. Patrik Löwendahl May 17,2007 08:31

    It should be mentioned.

    It lies in the same cateogory as “the broken window principle”, if one thing slips more likely another one will and then another and all the sudden your are in hell.

  3. anders May 23,2007 09:51

    You’re right, both of you.. I know I’ll have to mention it.. Now I’ll just have to find a way of doing it without sounding like an ass.. But hey, that’s actually one thing I’m usually pretty good at!

Comments are closed.