Software Developer, Mentor, Architect and UX/UI craftsman. Also, a psychology nut that loves curling. Zac is a DZone MVB and is not an employee of DZone and has posted 66 posts at DZone. You can read more from them at their website. View Full User Profile

Coding Standards Are Overrated

02.08.2013
| 4189 views |
  • submit to reddit

As a development team grows, so does its complexity. This complexity manifests itself in many areas including team member interactions, increased project administration, and evolving communication strategies. At some point in every team the question of coding standards is broached. Unfortunately, most teams agree to compile coding standards under the false pretenses of only their positive attributes. It's important to consider the unintended ramifications before introducing a new process. Start by defining what are "coding standards?" They are commonly a series of guidelines which include recommended programming style, practices, and other various aspects of developing. The most common benefits outlined are:

  • Coding standards encourage good coding habits.
  • Coding standards help prevent bugs in known problem areas such as memory issues.
  • Standards can be a helpful guide to junior developers.
  • Standardized coding makes more maintainable code.
  • Code is more legible through standardized formatting and comments.

All of the items mentioned above are excellent reasons to implement coding standards; unfortunately, in most circumstances the unrecognized pitfalls outweigh the benefits. The following section outlines these areas:
  • Some team members equate coding standards to a lack of confidence in his/her abilities. Others find standards such as spacing and/or comments to be micro-managing.
  • Coding standards stifle and discourage coding creativity. Some of the best code comes from an unfiltered mind.
  • They create unneeded stress within a team as members disagree with various standards. These discussions can spiral into negative, unproductive debates.
  • Each new rule adds to the overall complexity of implementation, enforcement, and maintenance of coding standards.
  • Each concession to a rule devalues the overall purpose of coding standards.
  • Coding standards distract from the larger goal of building, testing, and releasing functionality in a timely manner.
  • Deciding how to handle existing code that pre-dates the creation of a standard is a winless battle.
  • When a coding standard is not followed, what happens to that code? Must it be fixed immediately? How does that effect its testing, retesting, or release time lines? Some consider this code to be technical debt. That is a difficult label to apply to code if the violations are simply style related.
  • Proper enforcement of coding standards can consume an unreasonable amount of time.
  • The decision to enforce coding standards and its consequences must be embraced at all levels within a company. Most companies struggle to embrace doing something twice.

If coding standards are not the preferred approach, what is? Code reviews are an excellent replacement for coding standards. They can be completed at the preferred speed of each team. They are a positive teaching and discussion tool. As described in "Code Reviews: Understanding and Breaking the Stigma", they can be a great team building exercise by having different members participate. Speaking with another developer about coding has a human touch that a coding standards document lacks. Code reviews help developers focus on larger concerns such as architectural issues and provide a forum to offer other coding suggestions. Performing intermittent code reviews covers the key aspects of coding standards while avoiding most of their pitfalls.

 

Published at DZone with permission of Zac Gery, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Steven Goldsmith replied on Fri, 2013/02/08 - 10:20am

All I see here are a bunch of lame excuses for not using coding standards. Lack of confidence and creativity? Really? Most IDEs have plugins that check style and common coding problems (CheckStyle, PMD, FindBugs, etc.) prior to committing code to your repo. To use a code review for this is a huge waste of time. Use humans for functional and architectural review that the tools cannot flag.

Robert Saulnier replied on Fri, 2013/02/08 - 10:55am in response to: Steven Goldsmith

I agree with Steven.

Code reviews are not the place to discuss when to use curly braces.

Fabrizio Giudici replied on Fri, 2013/02/08 - 11:54am

Interesting post - I must say that my first reaction is with Steven and Robert. But let me go in deeper details.


First, it mostly depends on the contest. I see two extrema: small corporate, very agile, with a core of developers with a low turnover; and a medium-large corporate (which can be somewhat agile anyway), with a relevant number of external developers with a certain turnover. Also, in some industrial segments, coding standards are a quality requirement (see SIL for instance), thus if you fail to meet them is unacceptable, just as a non working application. Clearly in this latter case there's no discussion.


Then, in detail:


"Some team members equate coding standards to a lack of confidence in his/her abilities. Others find standards such as spacing and/or comments to be micro-managing."


The first objection can be true in a small team. In a team with turnover simply I don't want to be able to understand who wrote a given piece of code. Everybody should be able to understand, fix and patch any piece of code if needed, and this without asking "hell, what did that guy who left six months ago wrote". Micro-managing is about controlling every five minutes what you're doing, so it's a different matter. In a corporate I suppose there are even standards for configuring the workstations, for a number of reasons from security to efficience in maintainance, and this is not micro-managing.


"Coding standards stifle and discourage coding creativity. Some of the best code comes from an unfiltered mind."
"They create unneeded stress within a team as members disagree with various standards. These discussions can spiral into negative, unproductive debates."


Creativity is so important that it must be confined in the proper parts. Creatity belongs to architecture and design, not implementation (algorithm aparts). In a medium-large corporate there's a clear separation of responsibilities, so I don't expect developers to be creative, nor to debate the decisions made by architects and designers (which means: there's the proper time to discuss anything, and everybody should be able to make a proposal; then a decision is made and everybody comply with it).


"Each new rule adds to the overall complexity of implementation, enforcement, and maintenance of coding standards."


True, but we have tools. I've assisted a large corporate in implementing most of the coding standards in CheckStyle and Maven (it's all in the SuperPOM and other configuration file automatically enforced to all projects). This means that Hudson can automatically produce reports about their compliance and eventually reject a build if there's no compliance. Sure, this is a cost, but not so high if you already have a working CI environment (and you *must* have one).


"Each concession to a rule devalues the overall purpose of coding standards."


True. In fact, there must be no concessions.


"Coding standards distract from the larger goal of building, testing, and releasing functionality in a timely manner."


It is true when yesterday you didn't have coding standards and today you have. There must be a transition period to be defined, and in this period you'll sure spend some time - which could even be not-negligible - for respecting coding standards. After you get used to them, and for new code, the cost is very small. IDEs such as NetBeans can format automatically according to some CheckStyle rules when you use Maven.


"Deciding how to handle existing code that pre-dates the creation of a standard is a winless battle."


No, it isn't. It's a cost, of course. Basing on Hudson Checkstyle reports you write a script to create an Excel sheets where you partition things to do by category and developer. Then discuss with developers the cost of each category, and you guess how many minutes per each violation you have to spend, and plan how to deal with it in the following months. I'm talking with a real example in mind - I've assistend in doing this thing with a large corporate.


"When a coding standard is not followed, what happens to that code? Must it be fixed immediately? How does that effect its testing, retesting, or release time lines? Some consider this code to be technical debt. That is a difficult label to apply to code if the violations are simply style related."


In the transition period, nothing happens. After the transition is over, you define priorities for violations. Hi-prio violations are not accepted and Hudson would break the build. Others can be tolerated to accumulate in the technical debt for a limited time. You use temporal graphs in Hudson to verify that the technical debts doesn't accumulate too much (exactly in the same way as you do for Findbugs or failed tests).


"Proper enforcement of coding standards can consume an unreasonable amount of time."


As I said, with the proper process and tools, it's not unreasonable. It can be done - of course you have to balance costs and - as all the other things you do - it must be justified by a returned value, so you will define the coding standards with a pinch of salt (unless, as I said, there are quality constraints to comply with).


"The decision to enforce coding standards and its consequences must be embraced at all levels within a company."
Definitely correct. I add that sometimes the input comes from the upper floors that sometimes have more acquaintance with writing quality documents than with the developers daily jobs. This can be dangerous. The best things happen when policies are discussed together, shared, and the policy makers have a concrete experience about how people work.

Steven Goldsmith replied on Fri, 2013/02/08 - 12:43pm in response to: Fabrizio Giudici

You nailed it, let Jenkins do the dirty work of reporting code quality. Then the CI server is the bad guy and I'm not the one saying your code is crappy (plus your IDE is configured the same way, so you knew you checked in crappy code). You institute coding standards by committee and you will have a better chance at adoption (some of the default rules are controversial after all, so build consensus). Once you use these tools in your IDE you will not be making simple mistakes and you will start producing consistent quality code (at least from a non-architectural, non-functional perspective).

You also cannot have a conversation about code quality without testing. Your parent POM should have some type of code coverage tool like JaCoCo embedded that produces reports on what parts of the code you are testing.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.