Writing Quality Software - Code

Coding is bringing the architecture and design to life. Making the idea work. Correct coding is more than just writing code that runs and do what it supposed to do. Correct coding is about making sure the architectural principles are applied, the code is readable and maintainable, self explanatory and self debuggable. Keep in mind that code is meant to be read much more than it is meant to be written.

Debuggable Code

What exactly is “debuggable code”? Well, I would say a debuggable code is a code that helps you find where the errors are as you run into them. This can be done by:

• Emitting enough logs where applicable.
• Not “swallowing” exceptions.
• Placing a method result in a local variable and returning it, rather than return a computation.
• Preferring a full if/else when needed for populating a variable over the shorter form of x?a:b.
• Breaking lines between different statements, such as
  if (something) return;
  which is not debuggable, since you can’t place a breakpoint on the ‘return’.

Generally, if you try to debug a section in your code and think it is too hard to debug because the debugger is not enough feature rich, think again how you can change your code to fit the debugger limitations.

Correct Casting

Scott Peterson posted this post about casting best practices. There are several things I would like to add upon.
First, when you expect a specific object type, prefer static cast, even in the case of a publicly visible method. The reason is that you would like the CLR to check the type for you and throw the relevant exception. Why? The alternative is you doing it yourself and responding correctly. Most people would simply “swallow” that error, which will yield bizarre errors elsewhere (most common ones are a null reference exception much deeper in the code, and it would be a very tedious work figuring out what went wrong).

Readable Code

For each project, select a standard and stick with it. Keep in mind that in some cases you might need to read the code you’ve written outside the IDE. This means you won’t have all the cool features like tooltips specifying a member type, go to member, find member references, etc. You want to write code that will be easier to understand without jumping up and down the file.
While it sounds like the Hungarian Notation might sound like a good idea (you can know the type and scope just by looking at the member name), it is a very unreadable notation. I like the naming that adds “m_” and “s_” prefixes to class members and static members respectively, but I hate the addition of “p_” prefix to parameters as I’ve seen in several places. So basically, it is all about readability. Whatever you choose, make sure it is easy to read outside an IDE (using notepad is a good test case), and stick with it.
Another aspect of readable code relates to indentation. Indentation is not an option, my friends. It’s a must, and its better be done right. Select your favorite method of indentation (most common methods include 4 characters wide, 8 characters wide and “smart”), and make sure all indentations are using the same method (spaces or tabs). I personally believe that spaces are the best way to go (along with monospaced font), since the overall code “design” is kept in all editors. Liran Chen has a post about an indentation issue in Visual Studio (in Hebrew).

Spelling

Don’t underestimate correct spelling. And prefer English in your code and comments over any other language. This will be used as a standard that will ease the process of joining new developers to the project. Minimize the use abbreviations and slang. It doesn’t come out nice, and tend to look unprofessional.

These are my two cents of how to write better code, and there’s much more to write on that subject. Maybe in one of my next posts.

Update

Just found this post regarding programming:

http://sites.google.com/site/yacoset/Home/signs-that-you-re-a-bad-programmer

I find it true, helpful and funny.