A Distinction

Let us distinguish, please, the difference between a Software Pattern and a Software Habit. A pattern is something common and useful (feel free to debate this). A habit is, well, a habit might look like this –

#define U16 unsigned short
#define U32 unsigned int

and then using the resulting “types” all over the place in the fond hope that your code is somehow made better by it. Habits also include the reimplementation of string objects, linked lists, layers (upon layers upon layers upon untold numbers of layers) of networking “helper” code, memory managers, and so forth.

Habits are the code that happens between the time you have a good idea and the time that you have a good design. They are what busy little fingers do to kill time.

I once saw a library that essentially reimplemented bit shifts and some other low-level operations in a very involved, convoluted manner, essentially using loops, masks and a ton of function calls to accomplish what &lt< and &gt> do. When I asked about the library (the engineer in question “wasn’t around anymore”), I got the answer that (a) the person who had checked in the code had been carrying that code around for quite some time, and it was what he was used to, and (b) “Yeah, we know it’s written in <blah> and the rest of the project is written in <foo>, but he got real upset when we didn’t let him use it.” That little portable library was costing the product real cycles, and was causing real maintance issues.

Some old habits die hard. I’m a power Emacs user, but I wonder how much I’m missing from good integrated environments like Visual Studio 2005 (which I use mainly for the debugger). Unfortunately the Emacs commands are embedded in my nervous system at a very low level, and a sequence like C-A and typing a character — “go to the start of the line and insert x” — winds up replacing the whole edit buffer with “x” in Visual Studio. Thank goodness for multilevel undo.

Not really about habits, but –

I really wish that out-of-date documentation self destructed. Things are better if you can auto-generate documentation from code comments, but this is not so good for writing tutorials or other “verbiage level” (as opposed to API level) documentation. (And even with doc-comments, the comments are often either very sparse or out of date).

I’m pining for an inter-linked edit world (hello Xanadu!) where my sample code can reference working code snippets from the unit tests that exercise the latest APIs, and that everything just gets built up (… and transmitted to users? why not?) when the build happens.

I guess it’s another good reason to stop using Emacs, or write my own 🙂

This entry was posted in Uncategorized. Bookmark the permalink.