Comments on: The Boy Scout Rule

By: Hidden Dependencies Are Evil – Arguing With The Clean Code (Slightly) « The Holy Java

Sat, 19 Feb 2011 01:30:26 +0000

[...] without the new features he desired. And whenever we come back to an old code, we should follow the Boy Scoute Rule of software [...]

By: Hans-Eric

Hans-Eric — Tue, 27 Jul 2010 08:36:36 +0000

@Paul W. Homer I agree, Paul, but -- as you point out in your excellent post -- it can be very difficult to make everyone on a multi-personality team go by the common standard. Coaching and strong leadership is required to make it work. Another great post of yours, that touches the clean code topic, is Syntactic Noice.

By: Hans-Eric

Hans-Eric — Tue, 27 Jul 2010 08:06:02 +0000

@Madoc
Thank you for your comment. I like the idea of mapping natural language to code, even if – as in the case of your rule of thumb – the mapping is only made in the brain. I’m having a little trouble, though, imagining how this rule of thumb of yours works in practice. To make it clearer (for a thick-head like me), could you provide an example usage?

By: Paul W. Homer

Paul W. Homer — Mon, 26 Jul 2010 19:57:22 +0000

Usually my rule is: if you see that it is wrong, fix it now. However this doesn’t apply during a code freeze or in a death march.

I think all team should use one and only one consistent standard, not only for the formatting but also for the variables names and function names, and that standard should be driven by the domain first, then the technical domain. Still, over the years I’ve wondered heavily if this is really possible. That’s why I wrote:

http://theprogrammersparadox.blogspot.com/2010/05/personality-effect.html

Many programmers just don’t seem to grok that consistency would make their lives easier.

Paul.

By: Madoc

Madoc — Mon, 26 Jul 2010 16:09:36 +0000

I have a rule of thumb when deciding wether or not code understanding would improve from expanding compact regions of the code. Especially when the question is if one should expand a one-liner to several lines.

I ask myself: “When explaining in natural language what this part of the code does, would I put it all in one simple sentence? Or would I make several sentences (or maybe one longer, complex sentence that makes use of phrases like “the string we extracted before” or so, i.e. the natural language equivalent of variables)?”

When the answer is a very strong tendency to “one short sentence”, then I usually do not change the one-liner. Otherwise, I consider expanding it to several lines, which then depends on my intuition.

I found this rule of thumb useful. It illustrates that not the number of casts or operations should decide if the code is understandable, but instead the equivalence to natural language constructs. Because natural language constructs that feel “just right” to us make up the area of expressible statements that seem to belong to one integral unit of thought to us, not the number and nesting of the contained operations. Natural language is “clean”, at least for humans. Probably that’s because we have invented natural language in order to practical for us. Computer scientists seem to have a tendency to abstract too much; sometimes it seems like they would want to put all of this intuitive stuff of human understanding into one metric, one formula, totally ignoring that it is mostly subjective.