Opinion: Programming Languages Shouldn't Enforce Style, Teams Should
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?
Enforcing removes ability for optimization as well.
Also, I'd argue "good style" can't be enforced 100% by a tool. For instance, it is best practice/good style to avoid using exceptions for conditionals (i.e. trying something and then doing something if that fails) Unfortunately, not every API on the planet got that message and sometimes it's the only way you can do what you need to do. If the tool was to somehow enforce this idea of not using try...catch as if...else then you would never be able to work around these problem APIs.
Re: Enforcing removes ability for optimization as well.
We're in complete agreement (I can't speak for Reg here). However I've never encountered a case where bad style enabled me to fix a critical performance problem.
Usually when I find a performance problem there is a design problem not far behind. I've also noted that performance problems often show up in classes with high cyclometric complexity. Maybe that's because no one understands them.
We're also in agreement about the value of tools. Both PMD (Java) and FxCop (.NET) are very useful static checks. But the rules often flag false positives or issues that can't be avoided like the libraries that throw exceptions. My one caveat if you come across a library that throws plain Exceptions you have to wonder what other problems lurk under the hood. If it can't be changed then maybe you should be looking for its replacement.
Dunno if I buy this argument
I mean, yes, I think that you want to guard against unintended consequences, but I don't think languages that enforce 'good style' necessarily make people stop paying attention to style, it's just something to keep an eye on.
Similarly, with coverage tools, you can't afford to imagine that good coverage scores mean your application works and is well-tested, but that doesn't make them useless to me -- they can help you keep an eye on what code isn't exercised by tests, even if knowing that code is exercised by tests doesn't mean that it's perfect.
Re: Dunno if I buy this argument
I've also seen code coverage abused. A developer will say of a bug - but the code coverage tool indicates that we tested that line. Unfortunately the problem seems all to real.