Rants About Software

There exists programmers who do not love what they do... I know, I can't believe it either.

To many, software development is just an everyday 9-5 job. But to others (such as myself), programming is practically a way of life! But I suppose not everyone can have the same love for code that I do. Not everyone can really admire the elegance of a well-formed recursive function. Not everyone can read a piece of code and appreciate it in the same way that others might appreciate a song, film, or book. But the problem is not that there are people who don't love software. The problem is that there are people who don't love software despite the fact that they CHOSE a career in which they write it every day.

But how do I know? How do I know that the people writing software don't love it the same way that I do? How do I know that people chose to go all the way through school in order to start a career in a field that they don't love?

I know because I read their code.

Aesthetics Matter!

I look at ugly code ALL the time! I look at code with incorrectly indented code blocks. I see code with inconsistent variable naming conventions - that's if they even have conventions. I see poorly designed class interfaces, inefficient nested for-loops, execution paths that are never reached, vague documentation, the list goes on.

If you love what you do, then you should WANT to write clean code. It's not enough to just get the program working. Aesthetics matter!

You should always follow some form of coding guidelines - not because your boss says you have to, but because you WANT to. You should care about the readability and integrity of your code. Here are some sample coding guidelines from the C# Coding Standard that should help.

• Methods with return values should have a name describing the value returned, such as GetObjectState().
• Prefix private member variables with m_. Use Pascal casing for the rest of a member variable name following the m_.
• Avoid putting a using statement inside a namespace.
• Always check a delegate for null before invoking it.
• Avoid putting multiple classes in a single file.

Again, I'm not telling anyone to follow these exact coding guidelines. I'm just saying that you should HAVE guidelines, and more importantly, you should WANT to follow them!

Refactor Your Code!

All too often, programmers will get a piece of code working and then they'll abandon it and move on to the next task. Like I said before, it's not enough to just get your code working. You need to go back and refactor your code!

How often do you create temporary variables while debugging? Go back and get rid of them! Make sure there aren't any control paths that can't be reached. Improve the efficiency of your implementation by removing redundant code.

The end result should be a tight, concise, and clean implementation of your solution.

Make Your Code Communicate

This one can be a little tricky. For the sake of future programmers, who may someday be maintaining what you've written, you need to try to communicate your thought process to them through your code. So just how exactly do you do that?

Well the first, and most obvious, answer is comments. But having well-commented code is no reason to write bad code. First, you should program as if comments don't even exist. Use descriptive names, refactor your code, and get rid of the bloat. Make your code straightforward and easy to understand, and THEN comment it.

Of course comments can be used to communicate to other programmers, but how do you make your actual CODE communicate? Show them that you've thought of "everything"...

When creating a C++ class, you should always overload the assignment operator. However, this is not always necessary for the functionality of the program at hand. I don't care. Write it anyway. This will show them that you've at least thought about it. The same goes for default constructors and destructors.

When checking for user input, assume anything and everything may be entered, and handle it accordingly. Don't leave it up to the maintenance programmer to think of every scenario. He has enough on his mind with just trying to figure out your code and implement his change.

Consider all control paths. Are there any obscure/unlikely paths that you may not be handling very well. Perhaps these should actually be exceptions. If so, catch them accordingly, rather than having someone else spend hours tracing through your code with a debugger.

Improving our code shouldn't be a chore! It should just be a part of what we all do. We do it because we love it - because we care about the product, both inside and out.

Side Note: I hope Jeff doesn't mind, but I stole the above image from codinghorror.com.