There are some who believe that, if you write a large enough cookbook, then there will always be a simple recipe to follow to solve all our programming problems - this is familiar from the "Waterfall" development approach. Taken to an extreme, there are some who want programming languages that would limit developers to safe constructs and clean style. Reg Braithwaite skewers this belief:
If someone writes code in that language, they are absolved from all responsibility for its style. And so is their manager: the programmer's code compiled, it is demonstrably free of bad style, what can we demand of their manager other than to see to it that they use the language?Automation can be a good thing and we use it constantly, with our compilers and garbage collectors. Reg notes that it enables us to give up responsibility for some things that no longer matter. We've given up responsibility for churning out CPU instructions and memory management. So when we automate style we're saying that we've given up responsibility for it. From Reg again:
... what we have learned is that if we remove an individual's authority to choose, we absolve them of responsibility for the result, and ultimately performance suffers greatly even if their skills are objectively high.
So when we automate style, we are deciding that style doesn't matter. As long as it passes the compiler, it is good style.Reg's recommendation: instead, we should focus on which programming languages enable good style. We should focus on having teams agree on what they think good style is. Increase accountability and responsibility, don't take it away through automation.
Automating good style ultimately weakens the notion of individual and shared code ownership, it emphasizes the notion that if it passes the gate, it must be good. That, in turn, creates the illusion that no further inspection is required. If it functions as we require, and it is written in the language that enforces good style, why do we need to review it?