Write Less Code

August 27th, 2010

I have recently come across multiple sources that recommended writing less code or just enough code to get the job done. Fewer lines of source code mean fewer lines of code that needs to be documented, tested, and maintained.

In a situation where lines of code is not being used as a performance metric, lines of code should be minimized while adhering to a project’s constraints. A project’s constraints may require that the source code is readable. In the interest of security, it may require checks to be redundant. The project may also require the software to be compartmentalized with well defined interfaces. The need to add whitespace for enhancing readability, conditional statements to address security, and interface declarations to increase modularity will undoubtedly increase source code length. Writing less code should be done by writing only code that addresses the project’s objectives, and eliminating unnecessary or nonoperational code.

I have seen code implemented as follows:


int f( int x )
{
  int y = 0;
  if( x > 0 )
  {
    // some processing...
    y = 1;
    goto DONE; 
  }

  if( x == 0 )  
  {
    // some processing....
    y = 0;
    goto DONE;
  }

  if( x < 0 )
  {
    // some processing...
    y = -1;
    goto DONE;
  }
DONE:
  return y;
}

Using goto to handle cases in C or C++ where Java’s labeled breaks would be useful is arguable. The same arguments for the use of goto do not apply to the code that resembles the sample that is presented above.

Some may say that the use of an explicit goto, increases security by creating a redundant jump statement, one that is explicitly added to the other that is implicitly inserted into machine code by the compiler. After viewing the assembler code that is optionally generated by the compiler, it is proven for the situation that I experienced that the goto is ignored.

Though the goto statements are ignored by the compiler, they are distractions to people who read the source code. Rather than simply reading code that is well structured, a reader will need to search for the code label that is the target of the goto. The insertion of redundant jump statements is best implemented by the compiler. This reduces the noise that is introduced into the application source code.

In my most recent experience, minimizing lines of source code was accomplished by eliminating superfluous gotos. The updated source code is similar to the following:


int f( int x )
{
  int y = 0;
  if( x > 0 )
  {
    // some processing...
    y = 1;
  }
  else if( x == 0 )  
  {
    // some processing....
    y = 0;
  }
  else if( x < 0 )
  {
    // some processing...
    y = -1;
  }
  return y;
}

As a result, source code length is reduced, readability is increased, and testing coverage is simplified.

Watch Update Acquired!

August 17th, 2010

Swiss Army Active Original Red Bezel and Victorinox Swiss Army Classic Infantry Mechanical Self-windingMy parents gave me the Swiss Army Active Original with Red Bezel (#24221) as a gift for high school graduation, which had a retail price of 155USD at the time of purchase and is now sold by authorized dealers for 195USD. The Original features a Swiss analog quartz movement and scratch-resistant mineral crystal. Its strap consists of leather and nylon mesh with stainless steel buckle. The dial of the Original is white with bold black numerals and small red military time numerals. The Swiss Army Active Original is battery operated and water resistant, and its hand and hour markers are luminous. The day of month feature is the Swiss Army Active Original’s sole complication.

After 12 years, I upgraded to the Victorinox Swiss Army Classic Infantry Mechanical Self-winding (#24695). I purchased the timepiece, which has a retail price of 525USD, by special order through Classic Design Fine Jewelers at the Glendale Galleria. The Classic Infantry Mechanical Self-winding features a 25 jewel Swiss automatic mechanical movement, scratch-resistant sapphire crystal, stainless steel case, and a see-through caseback. Its strap is leather with a stainless steel buckle, and its dial is black with white hands and markers. Aside from the dial, the crown and buckle are embellished with the Victorinox Swiss Army logo. The Infantry Mechanical Self-winding includes two complications: day of week and day of month.

The transition from a quartz movement timepiece to one with an automatic mechanical movement has surely renewed my enthusiasm for owning and wearing a watch. The Victorinox Swiss Army Classic Infantry Mechanical Self-winding allows me to appreciate the awesome engineering feat that is accomplished in a quality timepiece.

A Microsoft Windows Media Video that presents the Victorinox Swiss Army Classic Infantry Mechanical Self-winding timepiece with an ETA 2836-2 movement operating at 8 beats per second is found here.

Trunk and Branch Management

June 1st, 2010

A real-world discussion about trunk and branch management that I found through reddit.com is reprinted here:

From: Rasmus Lerdorf
Subject: PHP 6
Groups: php.internals
Date: Thu Mar 11 12:22:48 2010

Ah, Jani went a little crazy today in his typical style to force a decision. The real decision is not whether to have a version 5.4 or not, it is all about solving the Unicode problem. The current effort has obviously stalled. We need to figure out how to get development back on track in a way that people can get on board. We knew the Unicode effort was hugely ambitious the way we approached it. There are other ways.

So I think Lukas and others are right, let’s move the PHP 6 trunk to a branch since we are still going to need a bunch of code from it and move development to trunk and start exploring lighter and more approachable ways to attack Unicode. We have a few already. Enhanced mbstring and ext/intl. Let’s see some good ideas around that and work on those in trunk. Other features necessarily need to play along with these in the same branch. I refuse to go down the path of a 5.4 branch and a separate Unicode branch again.

The main focus here needs to be to get everyone working in the same branch.

-Rasmus

From this post, it seems that the required “Unicode effort” was underestimated, and continuing that effort on the trunk is causing issues with development of PHP. The proposed change will move the Unicode effort to a branch, allowing development for other components of PHP to continue on the trunk. Changes to the rest of PHP on the trunk can be pulled into the Unicode branch as the Unicode branch continues to be developed. The Unicode branch can be merged back into the trunk once it is matured sufficiently.

The words, “trunk” and “branch,” are used to label lines of development work. In general, a trunk can be considered simply another branch. Identifying a specific branch as the trunk helps developers visualize its relationship with other branches. For the PHP development project, the trunk appears to be the main code base that is being developed. A branch isolates development of a feature, so that any impact it has on the main development effort is minimized. The Usenet newsgroup post above is an interesting example of the importance placed by developers in distinguishing between development trunk and branches.

Software Development Appreciation

April 30th, 2010

I recently finished reading Applied Software Project Management by Andrew Stellman and Jennifer Greene. Stellman and Greene’s book has motivated me to read CMMI for Development, Version 1.2. Since CMMI is a model for process improvement, Stellman and Greene’s book has also encouraged me to get books on processes such as Rational Unified Process and Personal Software Process.

Stellman and Greene’s book makes the case for software engineering practices in a general way, leaving a reader wanting knowledge of specific practices that are used. Their book starts strong with their introduction of the Wideband Delphi estimation technique, which is one of a few specific practices that are discussed in the book. Their script for inspections is also strong, clearly stating the objective of inspections and how to run inspections efficiently. The strength of the book tapers off when discussing requirements acquisition, planning, design, and testing. Overall, Applied Software Project Management is a good introduction to the components of software project management. Other introductory books on software engineering practices claim that writing documentation before performing implementation is good, but Stellman and Greene’s book explicitly states why and how this is the case, and their book surely makes me more appreciate software engineering practices.

A local copy of CMMI for Development, Version 1.2 is found here.

Problem Reports

March 31st, 2010

The responsibility of a project’s outcome is shared between developers and managers. Developers depend on managers to effectively manage projects, and managers depend on developers to provide reports that serve as the basis of project management decisions.

Possibly due to insufficient transparency, a problem may be detected after attempting to use a fully implemented and unit-tested software component. The integration phase of a software life cycle is a common, but undesirable, phase to detect interface issues. The problem, found during the integration phase, potentially reopens tasks that were considered complete. Design documentation might need to be updated, software might need to be re-implemented, and software might need to be retested. This increases the difficulty of meeting a project schedule, which may already be tested during integration.

The person that detects the problem has the responsibility to make the problem known. Resolving the issue among developers of the affected modules may be possible, but in general, resolution will involve too many people and too many tasks. Utilizing the managerial structure is pragmatic and effective in coordinating a resolution. A line manager or immediate supervisor is an entry point of using the managerial structure, so reporting the problem to that manager is reasonable.

Without a problem report, management is unaware of the problem and unable to manage the project with respect to the problem. Reporting the problem to management is a practice that increases project visibility. Management may decide that the problem shall not be resolved, because of schedule pressure or the severity of the problem. Management may decide that it shall be resolved within the constraints of the project schedule. Management may also decide to resolve the issue and revise the project schedule. Management must make the decision for the project, but the need for a decision must be made visible by developers through problem reports.