Random Programming Thoughts

[bcholmes]

It took me a much longer time than I'm proud of to see a difference between bad programming practice and different stylistic convention. Like the whole where-do-you-put-the-curly-brackets argument (when I programmed in C++, I put them on lines by themselves -- it made it easier to handle #IF/#IFDEF preprocessor instructions, and I still think it's easier to visually parse the code structure. But now that I program in Java, I follow the Sun conventions).

Every once in a while, I see something and try to figure out if it's bad programming or just different.

Thought Number 1:

There's a programmer that I've worked with at my current job. I have huge respect for his programming skills, but often had difficulty with his unwillingness to change his behaviour because of any process considerations.

One more than one occassion, I saw him implement a something like a cache. His implementations would always extend java.lang.Thread. The run() method would then periodically prune old items from the cache.

I always thought that this hugely strange. Me, I'd create a cache that holds on to a CacheCleaner class. I'd make the relationship compositional, and I might even make CacheCleaner an inner class because it's so specialized.

My cow-orker just didn't see that there was any difference. Now, a lot of people, I'd just tend to write off their implementation as bad, but I had a lot of respect for this guy. Nonetheless, it feels unnatural to me to say that a cache is a thread. I don't get it.

I think that part of my thinking on this has been influenced by an article I once read in Java Report that categorized methods into types -- getters/setters, command methods, initializers, factory methods, etc. In my mind, a thread object should really only have thread-related command methods; run() being the primary one.

(And, as an aside, I'm often amazed at the number of Object-Oriented developers who don't understand how the compositional relationship is different than a simple association).

Thought Number 2:

The Eclipse tool that I use for almost all Java development that I do has a number of cool features that help you spot unnecessary code. I can turn on a feature that marks all unused local variables, for example. It's cool for spotting a wide variety of mistakes and code bloat.

One of the features marks unnecessary else statements. Consider the following example:

if (firstName == null || lastName == null) {
    throw new InvalidNameException("The name is foo-foo");
} else {
    name = firstName + " " + lastName;
}

The tool would then tell me that the else was unnecessary and would suggest that I remove it. Me, I don't like that suggestion. I guess I always think about method implementations in the graph theory sense (yeah, I know too much about McCabe's Cyclomatic Complexity and crap like that). My code snippet has two code paths (one that ends with exception and one that does not. I like the way the if-else visual structure translates (in my head) to a code graph.

In my mind, to take out that else would be to treat the exception as a GOTO (which, yeah, in some senses it is).

But I've worked with a number of programmers who seem to be allergic to too many levels of indentation. They'll do anything to avoid a level of indentation. Me, I'll do anything to avoid something that smells like a GOTO.