Coding Standards – Should Teams Use Common Well-Regarded Standards?

ccoding-standardscoding-styleteam

The R&D team I'm in has decided to adopt a coding standard. We have only recently formed, and have too little code and common coding time of our own to base our standards/conventions document on what has developed organically in our team, and on good examples from our own code etc.

Now, every one of us has some experience from past workplaces – although none of us is at a state of saying "let's adopt this here comprehensive document I have found to be fitting for the kind of work we do here" (*). Plus, some of us (including myself) only have experience from places with no official coding standard, or writing in different languages in a different setting (high-pressure weekly-release production environment as opposed to more research-oriented development work)

So, one of the options I've been thinking about is taking a relatively well-known and well-regarded document, snipping off what we don't care about/care for, and making some modifications based on our preferences.

Is this a common practice? Do you believe this is a good idea? If so, what would be a reasonable 'baseline' coding standard (don't tell me which is best, I don't want to start a religious conflict here; just point out what would be comprehensive or 'neutral' enough to build upon.)

Notes:

  • We are expecting to work with C, C++, OpenCL, CUDA, Python.
  • We are a team of 4 people + manager, expected to grow to about 5-6 within a year or so.
  • In our company, teams are almost entirely autonomous and usually don't interact at all (not even by using each other's code – the work is on entirely different projects); so – no company-wide considerations to make.
  • Regarding tools, at the moment what we know is that we're going to be using Eclipse, so its code formatter is going to be one tool at least. Ctrl+Shift+F has long been my friend
  • When I write Java, I've adopted the practice of adhering as strictly as possible to Bloch's Effective Java. Now, that's not quite a coding standard, but you could call some bricks, cement and mortar for a coding standard. I was thinking of possibly including something like that as part of the 'mix' (minding that we don't do Java).
  • I mean coding standards in the wider sense of the word, e.g. adopting suggestions made in the answers to this P.SE question.
  • I've found a big list of C++ coding standards documents; maybe I should mine that our baseline.
  • (*) That's not quite true, but I don't want to complicate this question with too many specifics.

Best Answer

Put another way, you're asking if you should jump-start your team's coding standards by borrowing external standards that you've found. It doesn't sound like anyone on the team has super-strong opinions (yet) on what those standards should be.

Unequivocally, the answer is yes.

An externally sourced standard is superior to nothing. Look at the answers in "https://softwareengineering.stackexchange.com/q/84203/53019" in order to see some of the advantages for having a standard. Consistency and having a basis to change from are critical from your point of view.

Also have a look at "Handling Coding Standards at Work (I'm not the boss)" as it goes into some of the team dynamics that your team needs to consider when selecting what the standard(s) should be. The team needs to own their coding standard(s) so everyone willingly complies with the restrictions it places upon how each person codes.

You linked to this question, but it's worth pointing out the top answer and its focus on understanding why the requirements are in place. If you use an external standard, it will be hard for your team to understand the basis behind all of those requirements. But if you accept that they are there simply because your team needed something to start with, then it's easy to move on to changing that external standard to something that works better for your team.

Having any standard in place allows your to populate the formatting rules you'll use with your IDE (Eclipse in your case). "Advantages and Disadvantages of Forced Code Reformat" goes into the benefits for everyone on the team for having that consistency with the code they are working on, and gives you the ability to reformat snippets you may borrow from other projects. An added bonus of using an external standard is that it may already be pre-populated in the code formatting portion of your IDE.

Someone on the team will likely complain about a particular portion of the standard and will blame it on the fact that you used an external standard as the base. Have them read over:
- I hate one of our coding standards and it drives me insane, how to process it?
- How do you overcome your own coding biases when handed legacy code?
and then realize they likely would have complained about something within the standard no matter where it came from. Across the number of teams I have worked on, I have yet to see a standard that everyone a) universally liked and b) agreed with every portion of the standard. Reference back to some of the early links to see how to deal with those concerns.


Addendum, you asked about "which one" you should use. I'm specifically not going to answer that as any answer is potentially frought with opinion fueled flame wars. However, you could look at your IDE (Eclipse) and see what options it provides as standard configuration. I'd also search a bit and see if there are any projects that plugin to your IDE and provide additional standards options to pick from. Right or wrong, those standards are already populated for you and can save your team a chunk of work in configuring it for everyone.