Beefy Boxes and Bandwidth Generously Provided by pair Networks
Problems? Is your data what you think it is?

Re^3: Password Generation and Module Multiplication

by merlyn (Sage)
on Nov 23, 2010 at 15:59 UTC ( #873238=note: print w/replies, xml ) Need Help??

in reply to Re^2: Password Generation and Module Multiplication
in thread Password Generation and Module Multiplication

At the time, I think I had some warning that came up with the nested parens.
Which is why, in general, I don't add "use warnings" to the code I write. Sometimes, it finds useful things, but the only time it triggers for me now, it's simply annoying.

If you find yourself changing the code you write to be more obscure or hard to maintain because warnings are warning you, warnings have failed.

-- Randal L. Schwartz, Perl hacker

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

  • Comment on Re^3: Password Generation and Module Multiplication

Replies are listed 'Best First'.
Re^4: Password Generation and Module Multiplication
by sundialsvc4 (Abbot) on Nov 24, 2010 at 14:29 UTC

    Per contra, I always specify:   use strict; use warnings; ... and if there is any exception to that rule, I will place a no warnings "foo"; directive thereafter.   (If the unwanted warnings occur only in a specific block of code, the directive is placed on that block of code, then countermanded... and descriptive comments abound.

    In my experience, the warnings are usually correct; sometimes even prescient.   Computers simply don’t “overlook” things like aging humans do.

Re^4: Password Generation and Module Multiplication
by ysth (Canon) on Nov 28, 2010 at 07:57 UTC
    I have to agree here. "Possible..." warnings really should only be given where there is a trivial change needed to get the warning to shut up. In this case, I'd say the warning shouldn't trip when , is preceded by whitespace.
    A math joke: r = | |csc(θ)|+|sec(θ)|-||csc(θ)|-|sec(θ)|| |
    Online Fortune Cookie Search
    Office Space merchandise

      But that improvement doesn't go far enough. The "," and "#" warnings make me think it would be better to allow escaping inside qw. For example

      my @tokens= qw( $ \# ; \, if else else\ if ); # '$' '#' ';' ',' 'if' 'else' 'else if'

      The warning should be changed to:

      Unescaped ',', '#', or '\' in qw ...

      The trick is what level of deference to provide for backward compatibility of unlikely constructs. Silently changing the interpretation of qw( / - \ | ) would be bad. So I'd make qw( \ ) warn for a while before supporting escaped whitespace characters. I don't expect to find \# nor \, inside qw in existing code but maybe qw( \\ ) is slightly more common? That'd be the tough one to deal with.

      Maybe just add qqw() that supports escaping? I'd like to be able to even use \n, \t, and \x3e type constructs in qw() on rare occasions.

      I guess the current "fix" for the warnings is either no warnings 'qw'; or qw( . ? ! ), ',', qw( ; : ). I dislike the former as it can't distinguish the comma I meant to escape from the comma I slipped in by accident. So I tend to quickly end up replacing qw with quoted strings.

      Actually, I'd like qqw to ignore /\s#(\s[^\n]*)?\n/ as my desire to add comments is a common reason I end up replacing qw with quoted strings.

      - tye        

Log In?

What's my password?
Create A New User
Domain Nodelet?
Node Status?
node history
Node Type: note [id://873238]
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others musing on the Monastery: (4)
As of 2021-11-30 11:21 GMT
Find Nodes?
    Voting Booth?

    No recent polls found