Have there ever been any studies relating productivity to coding conventions?

Question

There is always a lot of discussion about various coding conventions, with strongly held beliefs on all sides. But I am curious if there have been any studies comparing equivalent projects where there were different mandated coding conventions, or even no coding conventions whatsoever.

I am especially curious as to what effect different coding conventions might have on programmer productivity - perhaps they feel they are "fighting" the system rather than working with the system?

Answer 1

IEEE: Productivity and Code Quality Improvement of Mixed-Signal Test Software by applying Software Engineering Methods

Answer 2

If you have too many rules and regulations you can end up treating your developers like "code monkeys". Giving people some degree of freedom can increase job satisfaction no end, and ultimately will lead to higher levels of productivity, rather than stifulling people in their jobs.

Answer 3

I think that each developer achieves maximum productivity by coding the way he is used to code . After all , even if there is a need for a specific coding convention , there are tools that can indent the code in that specific way ( eclipse has some )

Answer 4

This is my personal opinion on coding convetions.

In all my professional jobs the majority of coding conventions I've seen can be broken down into two categories:

1. Ego driven - do it the way the author of the convention does it
2. Micro management - place a space after a comma, indent braces two spaces, put case labels over there, use these hungarian notation prefixes (followed by huge table), etc.

which misses the point, in my opinion, of what a coding convention should be and generally doesn't aid productivity. How the code is capitalised and laid out is not relevant (apart from public APIs where it should be consistent throughout the library).

The really important stuff (which I've rarely seen) are things like:

• Documentation - ensure code is designed and documented
• Testing - ensuring code follows testing specification
• Maintainability - ensure variables and types have sensible names that describe their function
• Code review - the process of doing code reviews
• Source Control - details of source control system, who's responsible for maintaining the repository and so on
• Daily builds - who's responsible for maintaining it, what to do if it breaks

Code layout should be along the lines of "Stong Opinion, Weakly Held", that is, write the code the way you feel most comfortable with but adapt your style based on code you see others write (i.e. take the best ideas from other people's code).

Skizz