Click here to Skip to main content
13,189,884 members (51,742 online)
Click here to Skip to main content
Add your own
alternative version


15 bookmarked
Posted 25 Sep 2008

Simple Thoughts on Code Quality

, 25 Sep 2008
Rate this:
Please Sign up or sign in to vote.
For the software itself, it is easier to discuss its quality by measuring its performance, memory usage, number of the bugs etc. But what if we talk about the code file, how can we write code that we are proud of.


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.


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“.


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.


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.”


  • 25th September, 2008: Initial post


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Kivanc Ozuolmez
Software Developer
Netherlands Netherlands
No Biography provided

You may also be interested in...


Comments and Discussions

GeneralMy vote of 1 Pin
Guennadi Vanine11-Aug-09 5:04
memberGuennadi Vanine11-Aug-09 5:04 
There are plenty of quite elaborate Code Style guides, standards and best practices...

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web03 | 2.8.171016.2 | Last Updated 25 Sep 2008
Article Copyright 2008 by Kivanc Ozuolmez
Everything else Copyright © CodeProject, 1999-2017
Layout: fixed | fluid