Blog

Take a Stand for Codebase Standardization

Same line or next line? Tabs or spaces? Camel case, underscores, or dashes? Whether the debate is code conventions or naming standards most developers have their preference. And even if you don’t, you probably recognize these questions as falling under one of the most religious topics in software development.

Like most developers, I have my preference regarding conventions. I want my opening brackets on the same line. My file names? I can’t stand upper case letters, so give me dash separated JSP files. As for tabs, forget it. Spaces are undoubtedly the way to go. While these are my preferences, I have one that’s even more important: standardization.

The Psychology of Builds

Build times matter. Agile development and other pragmatic methodologies rely heavily on the practices of continuous integration, automated testing, and frequent builds. As build times grow, it becomes increasingly difficult to maintain the frequent use of these practices.

Automated builds must meet the restrictions imposed by natural psychological limits in order to serve their purpose. A build that is intended to be run during test driven development cycles must execute quickly so as to not interrupt the flow of development. A build supporting a pre-check-in smoke test that hangs mercilessly for ten minutes will discourage the exact practice it is intended to support. Build systems must be designed to meet their purpose.

Syndicate content