The Face Of Bad Code

Lets face it, we've all written bad code at one point or another. If we hadn't, we probably would never release any functional software. Remember, code that isn't ideal doesn't equate to code that doesn't run and help someone else accomplish some task. Code can always be re-factored, and, it should be re-factored.

I often find myself testing my own software from and end user perspective and thinking about the code that is running when I perform certain actions. I think "well, it works, but just barely". I have to force myself to think "well, it works, and that is all the user cares about; it can be re-factored later".

Don't be tempted to re-factor before you get something functional into the hands of the end users. Make notes on what doesn't work well and fix it in conjunction with the user-provided feedback. If you don't release, you don't get the feedback. Only you as the developer know what needs to be re-factored, only the end user knows how well your software solves their problem.

Code Bubbles

The Code Bubbles project looks like an incredibly cool way to edit code. Rather than have to navigate through an editor, it groups code elements into bubbles. There is much more to it than that but the general idea of better grouping programming language constructs in the IDE seems like a good idea to me.

After watching the demo, I can see a nice UML integration point for Code Bubbles.

Ugly Comments

This entry over at IT world talks about ugly comments in code and what that means about the code itself. Well, the basic assumption made is that if the comments in the code are ugly, so is the code. This assumption is derived from the principle of attention to detail. This attention to detail required by the programmers who write the code are not exempt from focusing attention to comments.

The problem is that the functional code and the non-functional comments really aren't all that different. I would argue that the comments are as much a part of the running program as the functional code is. They live in the same source files and are one in the same.

Writing great code doesn't really solve the problem of crappy comments either. In fact, the better the code, the more the sub-par comments will stick out. This doesn't mean going into great depths in annotating a piece of functionality. That will often add to the confusion. Go into depth explaining things outside of the source file. Make your comments in the source files concise but complete. Correct spelling doesn't hurt either.