RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Understandable Code Is Prosperous Code : Page 4

If you're the only one who can understand the code, your program's not done. Work through an XML schema validation problem in Java to learn the importance of writing software that others can easily understand, support, and enhance.

The Secret: 7 +/- 2 Rule
Studies dating back to the 1950s have shown that humans can most effectively process seven elements (digits, letters, words) at a time, give or take two. Known as the 7 +/- 2 rule, this principle is widely applied, probably without you even knowing it (phone numbers in the United States, for example). If you try to convey fewer than five elements at a time, you are missing an opportunity to convey more information in basically the same amount of time. If you try to convey more than nine elements at the same time, you will likely confuse the person ingesting the information.

If you really want to make an effort to get your code understandable to others, you should apply the 7 +/- 2 rule to many aspects of your software development and documentation, including the following:

  • Number of classes in a package
  • Number of public methods in a class
  • Number of lines of code in a method

If you're accustomed to writing hundreds of lines in a method, you're probably thinking the 7 +/- 2 rule will make your code inefficient because of the extra method call overhead. But a multitude of software engineering studies directly correlate method (or procedure before object-oriented languages were mainstream) size to increased levels of defects. And your huge methods take considerably longer for another developer to read and digest. Use the 7 +/- 2 rule and the people who maintain and enhance your code will be very appreciative.

As an added inducement, coupling and cohesion tend to fall into place when you design with 7 +/- 2 in mind. The longer the methods, the much greater chance you will have of tight coupling (causing brittle systems) and loose cohesion (causing great difficulty in understanding the system).

Step 2 Completed: Got the Code Understandable!
In the fast-paced world of software development, many developers never get to step 2—making the code understandable to others. Once the program works, they move on to another project, making it very difficult for others to support and enhance their code.

Todd Lauinger is the lead integration architect at Document Sciences. Todd has almost 20 years experience developing software and mentoring software engineering teams.
Email AuthorEmail Author
Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date