Code beauty

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 responses to “Code beauty”

  1. 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. 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. 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!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

About Me

Consultant, Solution Architect, Developer.

Do note that this blog is very, very old. Please consider that before you follow any of the advice in here!


%d bloggers like this: