Opinion: Programming Languages Shouldn't Enforce Style, Teams Should

Often, good style is less performant that junky style. For the vast majority of cases, the increased maintainability/ease of debugging that good style brings is usually more than worth the all too slight gains in performance of "bad" style. On occasion, however, the need to optimize weighs in heavily, and so you need to send out the style police out for coffee and donuts while you write a particular bit of code.

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.

Jim,
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.

Isn't that a lot like suggesting that code refactoring tools remove responsibility for improving code in ways that cannot be done with said tools, or that code coverage tools remove responsibility for ensuring that code works?

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.

Geoffrey - I'm not sure if the analogy with refactoring tools holds. However I will say I've had experience with PMD and FxCop where the developer has said of weak code: but the tool said it was OK.

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.