Summary
Recent years have witnessed the emergence of many high-quality tools that help enforce a consistent coding style. But how effective are these tools in practice, and how do they fit into your process of enforcing consistency in your source code?

In his essay on Self-Reliance, Emerson famously noted that:

A foolish consistency is the hobgoblin of little minds, adored by little statesmen and philosophers and divines. With consistency a great soul has simply nothing to do. He may as well concern himself with his shadow on the wall. Speak what you think now in hard words, and to-morrow speak what to-morrow thinks in hard words again, though it contradict every thing you said to-day.

It may be so, but few things can irk a good developer as deeply as encountering code that's inconsistent in its coding style. Most projects, indeed, define coding standards, and the Java language itself has an officially blessed style guide. For those who dream in code, especially, poor coding style means nightmare.

Some developers may argue that automated tools make it less important for developers to focus on following any particular coding style. IDEs, for instance, allow project-wide code style settings, and can even reformat code to adhere to a particular standard. Other tools, such as CheckStyle—which today released its new 4.3 version— can flag potential style problems in an existing code base.

While IDEs and style checking tools do an overall excellent job helping developers adhere to coding standards, I find especially IDE-based auto-reformatting less than practical: When auto-reformatting entire classes, the newly-formatted source files cause the source control system to indicate lots of code changes, even though those changes were only in formatting. The newly formatted version is really the same version as the previous one, unless we consider code reformatting a form of refactoring. Otherwise, ensuring consistency in coding style forces us to forfeit consistency in versioning (having a new version number indicate a changed source file).

In practice, I think that auto-reformatting code once in a while may be fine, but can cause confusion if used more often, especially on a package and project level. As a result, the automated tools notwithstanding, developers still need to carefully follow a project's coding style.

But what if they don't? I have certainly seen code written by fairly well-known developers that wouldn't pass a strict code-style check. In other words, excellent code, but with somewhat inconsistent style. At Artima, we have already integrated CheckStyle into our build process as a task we can run at our leisure to find style inconsistencies. But a clean bill of code style health is not currently a requirement for checking in code. We are thinking of a deeper integration, and I wonder to what extent others have required style checking as a condition of allowing commits, for instance.

I realize that part of this question relates to just how deeply we define code style. For there is a spectrum ranging from naming conventions, block coding style, and tolerance of code duplication, to the order of import statements and the treatment of white spaces. While tools can alert us of style violations occurring almost anywhere in that wide range, just how tight do you set the lever before the automatic code style police becomes a hurdle in developers getting their job done? And, more importantly, if you have followed automated style enforcement practices, to what extent did you see a correlation in developer productivity, or in just general developer happiness?

Talk Back!

Have an opinion? Readers have already posted 50 comments about this weblog entry. Why not add yours?

RSS Feed

If you'd like to be notified whenever Frank Sommers adds a new entry to his weblog, subscribe to his RSS feed.

Digg | del.icio.us | Reddit

About the Blogger

Frank Sommers is a Senior Editor with Artima Developer. Prior to joining Artima, Frank wrote the Jiniology and Web services columns for JavaWorld. Frank also serves as chief editor of the Web zine ClusterComputing.org, the IEEE Technical Committee on Scalable Computing's newsletter. Prior to that, he edited the Newsletter of the IEEE Task Force on Cluster Computing. Frank is also founder and president of Autospaces, a company dedicated to bringing service-oriented computing to the automotive software market. Prior to Autospaces, Frank was vice president of technology and chief software architect at a Los Angeles system integration firm. In that capacity, he designed and developed that company's two main products: A financial underwriting system, and an insurance claims management expert system. Before assuming that position, he was a research fellow at the Center for Multiethnic and Transnational Studies at the University of Southern California, where he participated in a geographic information systems (GIS) project mapping the ethnic populations of the world and the diverse demography of southern California. Frank's interests include parallel and distributed computing, data management, programming languages, cluster and grid computing, and the theoretic foundations of computation. He is a member of the ACM and IEEE, and the American Musicological Society.