Re: The Boy Scout Rule

[BrowserUk]

Booking.com

As the major contributor to their parent company's (Priceline) $4.8 billion annual revenue, $1.1 billion profit and $29 billion market cap., they appear to be doing something right. And given that their core business model has remained essentially the same since they were taken over in 2005, perhaps (part of) the secret that makes this Perl-based company stand out from its (original) peers, is that it hasn't succumbed to any of the fads that place the programming process and programmers above the business model.

Their basic business model hasn't changed; thus the required processes haven't changed much. When new code is required, it is very likely to need to do something very similar to stuff that already exists, and is proven to work.

You don't re-write (or refactor) code unless there is an identifiable, demonstrable reason that benefits the business revenue stream. Entertaining programmers is not such a reason.

Sure, there are times when it is possible to make the case that rewriting a piece of working code will benefit the business -- by improving performance; or simplifying (an existing, bad history of difficult) maintenance; or perhaps reducing runtime memory requirement by combining two or more similar piece of code into one. But the case needs to be made and demonstrated. First.

Opportunistic Refactoring

My take on opportunistic refactoring is different from the interpretation I read here. Rather than: I've got some time on my hands so lets go looking for something to change; I interpret it to mean: I am in this piece of code anyway -- due to a bug to fix or functionality to add or change -- and if I see something else here that can be (demonstrably) improved whilst I'm here, and then make a case for doing so.

Example 1.

First, I think your changes obfuscated rather than clarified that code:

1. You introduce two extra variables.
2. You didn't remove the repetition:

   just substituted 3 occurrences of a meaningless variable name for 3 occurrences of a self describing text constant; and four occurrences of another variable name, plus 4 integer constants (index numbers), that have to be visually cross-referenced with the actual, meaningful integers.

The original code is instantly clear and readable to its purpose; the refactor involves 3 levels of mental indirection to undo what you did.

The training element of introducing the programmer to map is barely justification for such changes.

And finally, if you have the time to faff around refactoring test code, you are under-employed.

Cleverness

I'm not adverse to clever code; but there is nothing clever about that. It's not clearer. It's not simpler. It's not more efficient. It's not even less typing.

Just obfuscate.

What would I have done?

Depends. If it was in test code; I'd probably insisted that the programmer that wrote it, described what it does and how it does it, in an adjacent comment, and then i'd pick holes in that description, until it was fully explained in excruciating detail. Something like:

1. It creates a list from the two scalars;
2. Constructs a two element anonymous array;
3. Compares the two scalars;
4. Converts the boolean result into an index;
5. Dereferences the anonymous array;
6. Applies the index to it;
7. Extracts the selected scalar from the anonymous array and assigns it to the result;
8. Discards the anonymous array it constructed.

And I would nit-pick that description until it was precisely, & exhaustively accurate.

I'm not suggesting the above is totally accurate; but the point is that teaching programmers to understand the consequences of their choices, is far more effective than laying down thou shalt/shalt not edicts.

If it was production code, I do the same; and then require it be changed to the ternary form.

[Discipulus]

Thanks for intersting read, unfortunately i cannot add nothing about code refactoring or reviewing because all the code i do at work is on my onw, i was never asked to write it nor someone has the ability to read it; i'm the one with the Perl mania..

About clever code. Many times (most? everytimes?) words and senteces hide the real sense or just mislead us about focusing on the right part. If you dismbiguate what 'clever code' can means you'll end with many different things and a bounch of questions.

First: who is clever? the code or the coder. And clever means the same if referred to a human and to a compiler?
When referred to a human a clever code(r) seems more near to tricky, ingenious and skillful: when you afford to understand lines of such code you think 'Oh wow it can be done in such way?' the same sensation as watching to a barman doing cocktails with flying bottles: beautiful, meaningless (in the sense that is not required) and risky. The same goal can be reached in plain, safer way with no downside (apart from the girl/boy impression effect).

By the point of view of a compiler i think that clever code could means: no unnecessary memory allocation and faster computation, no ambiguity. I suspect Perl prefere boring code, verbose and explicit one. You can add to the meaning also simpler, more readable and less typing because normally code writing is issued by humans so interaction is important.

So code is clever when has less requirements, use less memory-disk-network and run faster in the overall. Portabilty, robustness and maintainability also play. In such code the cleverness of the coder is not immediatly appreciable but is deeper and more effective.

That said, as i run on my own, coding in Perl has to be amusing too, so some tricky lines here and there can survive too to the quality inspection.

You said 'quality' please define 'quality'.. .. ooh no! ;=)

L*
UPDATE 27 01 2015: about quality, as found in blindlike's homenode:

As Albert Collins once said,
"Simple music is the hardest music to play and blues is simple music."
I'm trying to write simple code, just as hard as I'm trying to play simple music.


L*