Complexity Vs. Redundancy

September 19, 2006

I just wrote the following line of code as part of an implementation of a bucket sort.

Somehow I feel wrong inside about it. Look at it, it’s fairly complicated. In the context of the program you could work out what it was doing, but the effort would be made easier if it was rewritten as this.

Just splitting up that nasty math part from the method call clear up a bit of the ambiguity of what the line is doing, and the next version is even better.

While this doesn’t really tell you whats going on, it can lead you to finding the pattern involved. That pattern is described thus:

For an integer N, the digit X positions to the left of the least significant digit is: (N/10^X)%(10^Y) Where Y is a “look-ahead” to retrieve the next-Y digits as well.

Thats my informal definition mix for base 10 numbers, derived from a few dozen minutes of fighting with bc. I could put this information into the program, and then deciphering it’s workings would be a snap. But why? I mean, I’m never going to use this again, and if I need to, I worked it out the first time, the second shouldn’t be any harder. How much documentation is too much? How much is too little?

I hate bloated files, sources that are so filled with comments you never see any code. I think (like many before me) that code should be self-documenting as much as possible. I don’t belive in using in-line comments. They get in the way and don’t often help. But I’ve also always thought you shouldn’t break out the comment blocks for anything that wasn’t “serious”, so do I lower the definition of a “serious” comment, or do I throw away my would-be in-liners?

I suppose this is one of those things that comes with time, but I’ve tried to maintain old code before, that someone else wrote with zero comments, and it’s impossible. I think I’ll err on the side of caution, for whoever comes after me.

Categories: Geek
Tags: , , , ,

Leave A Comment

Your email will not be published.