Fighting Software Entropy - Intermediate
Recently I read an IEEE article on software metrics that identify potential dangerous constructs in code, such as brittle base classes. One short example: "Foo" declares and uses a method "bar()" that may be overridden by an extending class, potentially breaking functionality in the base class.
Metrics like this can really help to improve software quality. Considering the state of code that I see every day as part of my consulting business metrics like the one described above would be the final touch on top of a long list of measures and rules I would recommend to employ first. As long as methods with more than 200 lines abound, copying code is a design pattern, and "verifyOrder()" changes the delivery address in the data base you've got bigger problems to tackle first.
When washing your car you don't start polishing before you hosed away the mud - that would be spending a lot of effort in the wrong place. Getting rid of the mud takes 20% of the cleaning effort and gets 80% of the job done. When you optimize a program you first analyze where most of the CPU time gets spent and concentrate on these hot spots. Likewise, there is a rather small number of coding guidelines that go a long way to improve code quality.
Here is my hit list of the most important code improvements:
Nomen est Omen: The name should fit the meaning. Don't call a method "verify()" - the name strongly implies read only access - when the method changes data or even creates and deletes whole records in the data base. You don't like documentation? Well, choose good names; together with the next rules your code will be as easy to read as pseudo code. There is no excuse for bad names: refactoring has made renaming safe and painless.
One method, one purpose: If it is difficult to find a concise name you probably packed to much functionality into one method. Break the method in smaller method that each do only one thing, and make that thing the name of the method. Again, refactoring makes this simple.
Break down long methods and expressions. Introducing more local variables will not slow down your program; modern compilers will optimize execution better than you can (at least in this regard). Break down methods into smaller methods, too. You might even find redundant code that you can eliminate, or that methods become usable for other than the original purposes.
[This article is going to be extended]
Metrics like this can really help to improve software quality. Considering the state of code that I see every day as part of my consulting business metrics like the one described above would be the final touch on top of a long list of measures and rules I would recommend to employ first. As long as methods with more than 200 lines abound, copying code is a design pattern, and "verifyOrder()" changes the delivery address in the data base you've got bigger problems to tackle first.
When washing your car you don't start polishing before you hosed away the mud - that would be spending a lot of effort in the wrong place. Getting rid of the mud takes 20% of the cleaning effort and gets 80% of the job done. When you optimize a program you first analyze where most of the CPU time gets spent and concentrate on these hot spots. Likewise, there is a rather small number of coding guidelines that go a long way to improve code quality.
Here is my hit list of the most important code improvements:
Nomen est Omen: The name should fit the meaning. Don't call a method "verify()" - the name strongly implies read only access - when the method changes data or even creates and deletes whole records in the data base. You don't like documentation? Well, choose good names; together with the next rules your code will be as easy to read as pseudo code. There is no excuse for bad names: refactoring has made renaming safe and painless.
One method, one purpose: If it is difficult to find a concise name you probably packed to much functionality into one method. Break the method in smaller method that each do only one thing, and make that thing the name of the method. Again, refactoring makes this simple.
Break down long methods and expressions. Introducing more local variables will not slow down your program; modern compilers will optimize execution better than you can (at least in this regard). Break down methods into smaller methods, too. You might even find redundant code that you can eliminate, or that methods become usable for other than the original purposes.
[This article is going to be extended]
posted by Chris Treber at 01:38
0 Comments:
Post a Comment
<< Home