What’s wrong with straight-line coding?

The prevalent view of straight-line coding defines it as code with minimal branching, that is – based on certain conditions the execution will follow one path or another. I define straight-line coding as the method many developers follow by writing code from start to finish for each set of scenarios. Memories of attempting to plow a straight row in a field on a tractor involved picking an object at the end of the field and never taking your eye off it. Straight-line coders follow that same philosophy coding from point A to point B numerous times until all requirements are covered. One of the biggest problem with straight-line code is the maintenance.

Software maintenance can run as high as 50%-80% of development costs. In the early days of software development, emphasis was placed on making every single line of code count. The same was true for every I/O. This philosophy is not stressed with expanse of memory, megahertz, and DASD. There is an art to writing effective maintainable code. Before a program can be modified, it must be understood. In order for it to be understood, it should be readable and it should be designed such to withstand small changes.

The code shown in Figure 1 is taken from two software developers. At the time of this documentation, developer A had 5 years of experience and used straight-line coding. Developer B had 7 years and used a more structured approach to coding. The flowcharts depict software that was written to validate UPC/SCC for a national distribution chain. UPC is the Universal Product Code, the standard barcode used in identifying individual items. The SCC (Shipping Container Code) is the barcode used to identify shipping containers. Conditional branching, represented in the two flowcharts as diamonds, signifies a point in the program when a decision must be made. The rectangles in this figure represent calculations and data input/output processing. Execution of code flows from top down until a diamond is encountered; the program would branch based on the condition at the time of execution. The first diamond encountered in developer A code tests for the length of the UPC/SCC. If the length = 14, execution branches to the right, if not it continues to the lower diamond and tests for the length of 12. Developer A logic would have to increase by 20% in order to support all the scenarios as the code written by developer B.The most significant difference is that code generated by developer B is easier to read and maintain. This is not an issue of education or training; it is rooted in how developers have been geared to think.

This entry was posted in Uncategorized. Bookmark the permalink.