Most Read Latest News Blog Resources

Integration Watch: Better code through reading




September 15, 2009 — 
The programming section of Reddit occasionally receives posts from comp-sci majors and early entrants into professional programming who want to know about best practices for becoming a great developer. One of the consistent answers from experienced commentators is to read a lot of code. This is excellent advice because it’s the best way for novices to see what experts do and to become autodidacts in the techniques.

In the old days, this was difficult to do because there was not a lot of code available, and what was available was not a useful model. Neither TeX’s literate programming nor gcc’s twisted innards are likely to be what an earnest student is looking for. But with the profusion of well-written codebases today, code reading as an efficient means of knowledge transfer is now distinctly possible.

Two codebases I sometimes pore over are Tomcat (especially the Catalina container) and Cruise Control. Both demonstrate clean architecture, design and code implementation. I am sure if I looked at other code, such as JUnit, I’d find additional examples.

The benefit of this reading, beyond the mere qualitative appreciation, is that I have become aware of programming techniques—especially Java techniques, in my case—for rarely discussed problems.

For example, at startup, Cruise Control reads through certain directories and makes a list of all JAR files it encounters. It then adds those JARs to its existing classpath, so that it can incorporate any and all user plug-ins without imposing on the user to do more than put the plug-in into one of the searched directories. This approach is elegant and perhaps not the one I would have come up with by myself. I appreciate the good user orientation of its design; I know where to find the implementation. In the process, I also learned a lot about how classloaders interact with each other. Not bad for 200 lines of code, huh?

For prospective readers of code whose base language is C, I can heartily recommend Diomidis Spinellis’ excellent book “Code Reading,” which delves deeply into OSS C codebases, and serves as a very effective guide to reading code and knowing what to look for. It is, to my knowledge, the only book written on the topic.

The value of reading other coders’ work is slowly being recognized by pragmatists as well. Douglas Crockford, the inventor of JSON, says in the recent book “Coders at Work” that, “One of the things I’ve been pushing is code reading. I think that is the most useful thing that a community of programmers can do for each other—spend time on a regular basis reading each other’s code.”

This point of view is bringing into the mainstream two practices typically associated with Extreme Programming and agile development, respectively: pair programming and code reviews.

While pair programming remains controversial, code reviews are now a modern development activity. Consistent with this, we are seeing code review tools coming to market, notably CodeCollaborator from SmartBear Software, and Crucible from Atlassian. (By the by, SmartBear’s free book, “Best Kept Secrets of Peer Code Reviews,”—available on the company’s site—is an insightful and quick read for anyone doing code reviews.)

Perhaps the greatest immediate benefit from reading code accrues to developers who reread their own code. I am not talking about the quick double-check scan of code that takes place before a commit, but reading the code in—amazingly—hard copy. I recently began this practice at the urging of a fellow programmer and immediately came to appreciate its many benefits.

First of all, I simply see things that I gloss over on the screen. This is true for all content, not just code: Change the viewing format, and new items immediately stand out. Secondly, using the formatting options in IntelliJ IDEA, I can print easy-to-read, color-highlighted listings with 70 lines per page. I can then place two or three sheets beside each other and see the entire 200-line class in one sweep.

By getting rid of the monitor as a porthole into the code, I see the entire code. Suddenly, many refactorings and occasionally even design patterns spring to mind. I am looking at the forest and not the trees, which leads to different results. When I’m at the monitor, many of my refactorings consist of rename; extract method; and add, encapsulate and remove variables. When working from paper, I see higher-level opportunities: merging methods, extracting classes and so forth. My code is far better for it.

So, if you want to improve your code, read others’ work, then reread your own. If you do both, you’ll find code reviews of your contributions to be far more enjoyable.

Andrew Binstock is the principal analyst at Pacific Data Works. Read his blog at binstock.blogspot.com.


Related Search Term(s): programming techniques


Share this link: http://www.sdtimes.com/link/33767
 

Comments

09/16/2009 12:52:28 AM EST

Learn the Hungarian Notation. Having programmed in many languages, from Assembly for different processors to extensive C++ programming, I can say the Hungarian notation is a must for writing reliable code. The Hungarian notation makes it easier for team members to communicate and read each other's code. In a nutshell, the Hungarian naming convention is one technique among many that helps programmers produce better code faster. I personally extended the original Hungarian notation for classes, interfaces, methods, member variables, static variables, global variables, objects, arrays, bitwise operations, memory allocation cycles, error handling, exception handling, and data flow to name a few. There are many other benefits of using the Hungarian notation such as finding bugs at compile time and finding bugs during code reviews. People rejecting the usefulness of the Hungarian notation never grasped the idea of using the compiler as a debugger.

CanadaDaniel


09/16/2009 02:28:55 AM EST

Great article and great suggestion. From now on i will also read my code!

South AfricaMuzi


09/16/2009 02:37:22 AM EST

Carefully reading your own code is an interesting piece of advice that hadn't occurred to me. It can indeed be enlightening, especially if you read your code a few years after you wrote it. It can be a humbling experience. If on the other hand you still find it perfect, it means that your skills are not progressing: a worrying sign.

GreeceDiomidis Spinellis


09/16/2009 08:48:08 AM EST

I would recommend reading a copy of "The Elements of Programming Style", maybe a bit dated but good solid information.

United StatesRichard Moore


09/17/2009 01:40:19 AM EST

I have gone through "Code Complete" by Steve McConnell. It is a fine book. My suggestion is, after going through that book, if we are doing this code reading, it would help in improving the code to greater extent.

IndiaAmar@acmet


09/22/2009 10:30:17 AM EST

Good article, writing readable code we might rule the world!

MexicoJavier Torres


09/23/2009 11:30:17 AM EST

Concerning the tools used for printing code listings, the "trueprint" application on Unix is something I've used for many years. It facilitates printing listings of multiple files, with file and function indexes, indent levels, and other features. For the nearsighted (like me), it has an intelligent 4-pages-per-page mode, which gives me an even wider view in less space.

United StatesDavid Karr


Add comment


Name*
Email*  
Country     


  • Comment
  • Preview
Loading



 
 
 
 
News on Monday
more>>
SharePoint Tech Report
more>>


   

 
 
Download Current Issue
ISSUE 3/15/2010 PDF

Need Back Issues?
DOWNLOAD HERE

Receive the print Edition?


 
blogs tab
Google Code turns 5
Google Code Turns 5, and adds a Paxos Algorithm to make the system more stable and reliable.
03/17/2010 11:16 AM EST

Test your Visual Studio 2010 know-how
Microsoft is offering free beta certification exams for Visual Studio 2010.
03/17/2010 11:08 AM EST

Microsoft lifts the hood on IE9
Microsoft is previewing IE9.
03/16/2010 01:10 PM EST

 

Events calendar tab
3/22/2010 to 3/25/2010
Santa Clara, Calif.
The Eclipse Foundation

4/12/2010 to 4/14/2010
Las Vegas
Penton Media

4/12/2010 to 4/15/2010
Santa Clara, Calif.
O'Reilly Media

4/19/2010
New York City
Flagg Management

4/25/2010 to 4/28/2010
Overland Park, Kans.
IIUG