in reply to Re^3: Undefined vs empty string (not length)
in thread Undefined vs empty string

5.12? *sigh* I've adopted that idiom too quickly, then. We are still at 5.10 at work (and 5.10 was brand new at the point we started the process of upgrading to a new Perl so it may well be a while before we finish the next jump in version numbers even if we started that right now -- though I expect the next attempt to happen significantly faster given the lack of Solaris and not also doing an upgrade from Apache 1 to Apache 2).

Though, I find that in a large majority of cases, '0' is not a meaningful value and so "! $s" and "$s || ..." are just fine. But it is annoying that the only moderately infrequent case of "undef and empty string mean 'unset' but '0' does not" requires testing the variable twice in order to deal with it (without risk of warnings).

Some readers might like to know that using "not length $s" can easily bite one in quite mundane situations. I'd only use "! length $s".

- tye        

Replies are listed 'Best First'.
Re^5: Undefined vs empty string (! length, v5.12)
by Anonymous Monk on Jun 05, 2013 at 06:55 UTC

    Some readers might like to know that using "not length $s" can easily bite one in quite mundane situations. I'd only use "! length $s".

    Not so much I think, I can't remember the last time happened, but then I like to use or and and and () and not && and || :)

[reply]

      Just because there are a lot of mundane situations that can lead to problems, doesn't mean that you in particular have recently run into any of them, of course.

      But my point was that a lot of average Perl coders who decide to copy the "not length" usage can easily end up introducing bugs in several different quite mundane ways. And that pointing this out might encourage some to do the research to figure out why or, if already aware, to just be reminded to take care.

      'or' and (to a lesser extent) 'not' and 'and' were designed for use as flow control and work well for that (at least for those who don't mind such idioms). You can certainly bend them to the purpose of simple boolean expressions, but the required bending is somewhat subtle, is not needed in many situations, and can often lead to errors that are only triggered in relatively rare "edge cases". I find this makes the risk unacceptably high of real bugs making it all of the way into Production if one starts frequently using 'not' for boolean expressions.

      And when I got around to looking, I quickly found that my suspicions were confirmed and more than once, even for code from our best Perl coder. So I'm less shy about pointing this out, now.

      Clearly, you are much better than any of our Perl coders. But a few people read this web site despite only being better than some of our Perl coders. q-:

      - tye        

[reply]
[reply]

In Section Seekers of Perl Wisdom