in reply to Re^6: The Boy Scout Rule
in thread The Boy Scout Rule

Whilst not pretty, it is pretty simple and clear.
I beg to disagree. I recently implemented new features that needed to exit, but I had to literally experiment with all the possible combinations of exit statuses and AndExits to find the values leading to the expected behaviour. There's no documentation and only the comments shown. I'd think that "and exit" means "exit", not "and exit if not called from the command line and the number of errors is greater than some arbitrary constant plus a global variable whose value changes in 10 more places, good luck".

Otherwise, you're right. The global state is enormously large and contains lots of magical hashrefs as the one shown in Can you use string as a HASH ref while "strict refs" in use?. Also, many subroutines start with a boilerplate of 

my ($i,$j,$k,$l,$m,$n);
my ($Results,@Results,%Results);

[download]

You know, just in case you needed a variable, but couldn't declare one. One or two of them are actually used sometimes, but you never know which ones.

لսႽ† ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

Replies are listed 'Best First'.
Re^8: The Boy Scout Rule
by BrowserUk (Patriarch) on Jan 27, 2015 at 20:36 UTC
    I beg to disagree. I recently implemented new features that needed to exit, but I had to literally experiment with all the possible combinations of exit statuses and AndExits to find the values leading to the expected behaviour.

    I meant the code rather than the logic. And I did say my inspection was cursory. (After a second, equally cursory inspection, it looks like the (il)logic is all there; but it would need consentration or a paper walk through (or experimentation) to tease it out.)

    However, the need to add additional functionality sounds like the ideal time to refactor the internal logic of the subroutine. Or at the very least, an ideal opportunity to at least document it a little.

    the one shown in Can you use string as a HASH ref while "strict refs" in use?.

    That's a doosey. But ... (you knew that was coming right :), I suspect that the technique used was probably quite common (and perfectly normal) back in the Perl 4 days.

    (Note: I never used Perl 4; but I do remember seeing a very early version of Shell written by Larry Wall, that used techniques that today we would baulk at completely, but ...)

    All said and done, when you use a package global, all you are doing is adding a key into a hash (the stash or symbol table hash); and all that code is doing is using the value held in one variable as the key in that hash.

    Today this practice is condemned as Why it's stupid to `use a variable as a variable name', but the suggested replacement for this -- using the variable as the key into a hash -- is actually exactly what is being done in the condemned practice, with the only difference being the visibility of the hash in question.

    The replacement, using a lexical hash, thus contained scope, is better; but before lexicals were available, a lot of perfectly functional -- and assuming familiarity with the techniques used then -- perfectly maintainable, code was written that way.

    Also, many subroutines start with a boilerplate of my ($i,$j,$k,$l,$m,$n); my ($Results,@Results,%Results);

    As those are lexicals and contained within subroutine scopes, it seems to me they are a low-risk, no-brainer, target for cleanup. And if the management cannot be persuaded of that, then I think I would be looking for employment elsewhere also.

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority". I'm with torvalds on this
    In the absence of evidence, opinion is indistinguishable from prejudice. Agile (and TDD) debunked
[reply]
[d/l]

In Section Meditations