Your Ad Here
Sep 26

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.

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

 

And 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:

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


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.

 

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

Steve McConnell : "Good code is its own best documentation."
 

Number of Lines 

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

If you consider two software which function the same, the well structured one has always the less lines of code. The one has less lines of code is easier to maintain and fix the bugs. Which means the lighter is 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 the 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 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 times. 

Comments 

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

Exception Management 

Although we are just focusing on the code quality (not the architecture or the software quality) still we need to discuss the exception management. Any unexpected situation can cause the exceptions. Normally the newly started developers go to the solution directly but prefer not to think about any abnormal situation 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. Fixing the problems in early stage will have massive returns in the long term.  Searching for the perfect coding 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.”
 

credits goes to CodeThinked

kick it on DotNetKicks.com
 
Tags:
Software Blogs TopOfBlogs