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

Posted by Mark Levison on Feb 10, 2008 06:40 AM

Community

Agile

Topics

Code Analysis ,

Delivering Quality

Tags

Value & Metrics ,

Coding Standards

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?

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

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:

So when we automate style, we are deciding that style doesn't matter. As long as it passes the compiler, it is good style.

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?

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.

1. Back to top

   Enforcing removes ability for optimization as well.

   Feb 11, 2008 11:41 AM by Jim Leonardo

   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.

   Reply

2. Back to top

   Re: Enforcing removes ability for optimization as well.

   Feb 12, 2008 8:19 PM by Mark Levison

   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.

   Reply

3. Back to top

   Dunno if I buy this argument

   Feb 13, 2008 3:53 PM by Geoffrey Wiseman

   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.

   Reply

4. Back to top

   Re: Dunno if I buy this argument

   Feb 14, 2008 7:42 PM by Mark Levison

   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.

   Reply

• Older >