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.
