What scientific support does some coding standards have?

Question

Let's consider the rule in python PEP8, coding standard for the linux kernel etc saying that a line of code are not allowed to be longer than N characters.

To this rule there is normally a few rationales:

• On some terminals you can't see more than N characters on a line without wrapping.
• Optimal line length for readability is 66 characters.
• You should not use too many levels of indentations.

I kind of accept the first and last as having scientific support... Let's consider the second rationale, I understand that there's probably some investigation that has concluded that 66 characters per line is optimal, but I also suspect that this is for running text of natural language. Is there some results from investigating if this is true for programming languages as well? Btw this kind of result would suggest that one have to limit the effective number (without counting indentation spaces) of characters per line.

Another case which sounds like being a matter of opinion is how to name variables. There's all kind of options (depending an language) different variants on camel case and underscore (or minus) separated words (and you can of course combine them too). Is there any proofs that one of them is more readable than others? Or is it just a matter of opinion?

Answer 1

In software engineering, few insights are gained through science. Instead, experience and completely unfounded beliefs shape our decisions. This is partly due to the young age of our field (software engineering as a field emerged in the late 60s), but mostly due to the fact that human psychology can be quite difficult to measure.

Many people have tried to run studies to kill the most contentious debates with data. Does static typing or dynamic typing improve programmer productivity? Is camelCase or snake_case more readable? Do projects using TDD finish faster? While some of these studies have produced interesting results, most of these have methodical problems:

• Very small sample sizes. You can't generalize from 20 probands.
• Non-representative sample structure. What turns out to be good for undergraduate students that just completed their first Java course might not be best for you.
• Lack of control groups. What baseline is the study comparing against?
• Very subtle effects. Programmers are humans, which means they can be very diverse. It might be hard to spot any significant effect through all this statistical noise.

As a consequence, many studies are taken more seriously than they should. In particular:

• For weak effects, you might see multiple conflicting studies.
• Studies tend to be cited by those who feel validated by that study, ignoring conflicting studies.
• Most people (including me) never read past the abstract and are unaware of methodical shortcomings.

For a thorough discussion about studies on a single topic, please look at Static vs. dynamic languages: a literature review by Dan Luu.

To summarize: studies exist but they tend to be almost useless. For the time being, we will have to rely on our intuition and experience.

There is another take away here: Different approaches are not inherently superior to another, or only by a small margin. I have decided that I for myself prefer kebap-case over snake_case over camelCase, but that doesn't mean I'm going to convert everyone to snake_case: if there's any measurable effect, it's probably negligible. More important than either convention is being consistent. If I work on a camelCase code base, I just use camelCase.

And that's how coding conventions are created: someone writes down what they have found to be best practices, and then everyone sticks to that. If there's a really idiotic rule in the coding standard that violates common sense (or is just really unusual), then you can probably argue for that to be changed. But most topics like line length or variable naming conventions or brace style are not that important. I have more interesting problems waiting to be solved.