Creating and enforcing
coding standards, or coding style guidelines, is one method by which software
companies can ensure that source code written by a software developer is easily
understood, while being maintained by any other software developer in their
employ. Smashing Magazine contributor Nicholas C. Zakas penned an article titled,
“Why Coding Style Matters”, illustrating the value realized by creating and
adhering to coding standards. He states
that standards ensure individual members of a development team are able to tailor
the visual appearance of their source code while still allowing their
individual talents to flourish.
Standardized coding style also ensures better communication between team
members by allowing the product of work to act as a form of documentation for
the creators to leave clues for themselves and for others who come after. Potential programming errors are more easily
identified when a group of programmers adheres to a coding standard since any
code that does not comply becomes more visible and draws scrutiny of other
developers. Standardizing the code
comment, which is a way for developers to create non-executing code strictly
designed for inter-developer communication, is a good way to ensure other
engineers are able to understand why code was written in this specific way to
accomplish the known task.
Zakas begins the article by discussing his own introduction to coding
standards as a student in college. One
of his professors considered the style with which code was written equally as important
as the execution of the code. His
definition of coding style is insightful as it illustrates that the standard
can be as generalized or granular as the creator desires. All individual developers inherently have a
coding style, whether formalized and forced or inadvertently formed in
seclusion over time. The biggest challenge with a standardized style to a
creative group, he states, is the undeniably personal nature of any style. Mr. Zakas created a memorable simile
regarding individual musicians in a band.
While all of the musicians have a talent on their instruments, unless
they are orchestrated in some fashion beyond their individual creative style,
the music they produce will not likely be enjoyable to the listener. The structure provided by band governance for
items such as tempo, key, and lead timing, ensures a quality musical product
without forcing the conformance of individual creativity. That is exactly the marriage of the individual dynamic
within a team structure that is required. Prior to enforcing standards, you have to understand the challenges and resistance will be based on individual styles and creativity being 'standardized'. It is vital to communicate that coding standards and style guides do not throttle creativity or individualism, they simply channel it into a team effort and ensure forward progress.
Communication is a natural and valuable byproduct of coding
standards. Most communication within a
group of developers is resident within the source code itself. The output of any developer’s daily work is a
complete, exhaustive, and readable trail of every task he or she executed. When one developer reads the source code
created by another developer, the original developer’s view of the problem,
strategy to correct it, and final solution are communicated to the second via
the code itself. Once you reach this
realization alone, it indicates the need for standardization. The code communication is also useful for
developers to leave clues for themselves in the future. It is equally important for the author of the
code to understand that he may need to maintain a creation of his own in the
distant future. Intellectual breadcrumbs
and standardized formatting will ensure that old code and new code look the
same to the maintaining programmer.
Coding standards bring potential software errors
into view more easily. As programmers become more acclimated to specific patterns, they will more
naturally notice code that does not adhere.
This ultimately draws the attention of programmers and causes them to
consider the segment of code more closely, as it is an anomaly. Since the coding standard itself is designed
to enable consistently stable source code, one must focus on which items to
standardize with direct intent. You will probably not find a coding style guide with too much detail, but can find them with too little detail. The importance in your level of detail is based on the importance of ensuring items that are standardized are complete and
targeted at specific items important to the individual team. In other words, its not a good idea to standardize every aspect of development, just for the sake of doing it. You should focus on standards as they align with your business need and allow the developers to leverage their creativity and talent within the style guide.
