Simple Thoughts on Code Quality

Introduction

For the software itself, it is easier to discuss its quality by measuring its performance, memory usage, number of bugs, etc. But what if we talk about the code file, how can we write code that we are proud of.

Some of the topics to measure code quality are as follows:

• Clarity
• Number of Lines
• Performance
• Comments
• Exception Management

Many other topics can be added to this list for code quality measurement. But we will focus on these five now.

Clarity

Probably you have seen a really “smart” code like the one below:

public static int GetNextSize(int i)
{
  //multiply it by four and make sure it is positive
  return i > 0 ? i  << 2 : ~(i << 2) + 1;
}

At least we have a comment line; well we will discuss the comments later on. But as you see, you should really focus and evaluate the code before understanding what it is doing. So hiding the code in this way, especially if you work in a team, will create big headaches for your team members and after a while, for you, too. Code should always be clear and transparent for everyone just like the one below:

public static int GetNextSize(int i)
 {
   return Math.Abs(i * 4);
 }

According to Steve McConnell:

"Good code is its own best documentation."

Number of Lines

Some developers are proud of their large number of code lines because this is a proof to show how big the project is. But on the other hand, this is not true because more lines of code means more complexity, harder to maintain code base or even worse; wrong implementation of object orientation or code reuse.

If you consider two software which function the same, the well structured one always has lesser lines of code. The one with less lines of code is easier to maintain and fix the bugs in. This means the lighter, the better.

Let me quote Bill Gates:

“Measuring programming progress by lines of code is like measuring aircraft building progress by weight“.

Performance

Of course, a fast functioning program is better than its slow versions and the performance considerations are always in the front lines of the development process. But changing a clearly readable code to its complicated and fast equivalent lines is not always a brilliant idea and there is always a way to implement the same algorithm in a clearer way.

Well, I don't mean don't think about performance optimization but there is always a bigger chance in the overall system to optimize. It is more important to focus on the big picture and solve performance problems that are system wide, or refactor code so that changes can be made much faster, than it is to solve a performance problem in a single line of code...unless of course, that line of code is being called millions of times.

Comments

Again I am pretty sure you have seen so many uncommented or inadequately commented codes. Even if code, itself, is readable or not, comments are important substances. You should always keep in mind to write clear comments like you are telling it to someone else. Don't type them in your language, but in a common language.

Exception Management

Although we are just focusing on the code quality (not the architecture or the software quality), we need to discuss exception management. Any unexpected situation can cause exceptions. Normally the newly started developers go to the solution directly but prefer not to think about any abnormal situation that can occur in their solution. So any missing control or a direct assumption can cause a crash in your application.

In the worst case (probably the simplest), you can catch any exception on Application Domain level and show a common error message screen. But in any case, you shouldn't let your software crash!

As you already figured it out, it is not really easy to balance and find the most correct way of coding. If you don't like the code you've written, take a step back, review it, fix it, refactor it till you are proud of it. Fixing the problems at an early stage will give massive returns in the long term. Searching for perfect code will lead you to a better understanding of what you are doing.

And one more quote from Martin Fowler:

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

History

• 25^th September, 2008: Initial post