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:

Comments

Paco

Posted on Friday, 26 September 2008 23:48

I totally agree with the story, but not with the example. Sometimes you might need to write obscured code like the first example to catch an integer overflow exception. In the second example, you assume i is greater the int.MinValue * 4, so you still have to write a comment that the method only accepts a value range and not just all integers. You also have to assume that other programmers that use the method, actually read the comment.

Mathias

Posted on Sunday, 28 September 2008 07:07

On performance, I agree with your position. My experience has been that I was usually wrong when I tried to guess where performance issues would happen. Better build a good overall system, with a clear design and easy to maintain, and if it is not performing well enough, then run profiling tools to figure out bottlenecks.
Thanks for the quote by Fowler, it is interesting. I would add that great programmers write code that humans can read, and which has great performance...

Coskun SUNALI

Posted on Thursday, 13 November 2008 23:54

There is no need to discuss about exception management, performance and comments at all. But this "clarity" thing is really, really and really an important point that all developers must think of.

Nice article!

Busby Test

Posted on Saturday, 29 November 2008 13:12

thanks for sharing the code.

Busby SEO Test

Posted on Saturday, 29 November 2008 13:13

thanks for sharing the code.

busby seo test

Posted on Wednesday, 24 December 2008 23:24

many thank for this post

Thibauld

Posted on Sunday, 28 December 2008 18:15

In my opinion, clarity is also achieved through "small" functions / method. I particularly hate this kind of "do_stuff()" functions that handle too many things with a lot of nested "if/else" inside. I have a metric for this... I used to say that if I need to scroll to see where's the "else" of a "if", then there might be some optimization possible. It's not a dogma of course, sometimes you have to write large functions but it must not be the default.
Thanks for the post!

Busby SEO Test

Posted on Friday, 23 January 2009 08:28

what a useful post, thank you for make it.

Criminal Background Check

Posted on Monday, 20 April 2009 16:12

Thanks for a nice and informative site. Somehow I was drawn to reading the post and I enjoyed a lot. Have a nice day!

free insurance quotes

Posted on Sunday, 26 April 2009 01:37

very nice site, i really like it.

tukang nggame

Posted on Tuesday, 23 June 2009 01:37

thanks for taking the time to sharing this with us

Software Blogs TopOfBlogs