Beefy Boxes and Bandwidth Generously Provided by pair Networks
Perl-Sensitive Sunglasses

comment on

( #3333=superdoc: print w/replies, xml ) Need Help??
I will spend (waste?) more time for answer this thread.

Not a waste of time. Robust discussion of style issues in the context of code maintainability, without getting inflammatory, is time well spent in a public forum such as this.

You may not interpret that code as obfuscated or intentionally obfuscated.

I don't understand that.

Secondly obfuscation is a point of view, e.g. it depends on reading/writing style, which differs as Perl greets TMTOWTDI idiom; and it depends on demands of maintainability (which are not mentioned in this node).

I agree it is somewhat a point of view. That is, there is a large murky area between two reasonably clear extremes. And context plays a large part in where it is reasonable to draw a line between what is acceptable practice and what is not. In the context of a one liner as demonstrated above maintenance is not an issue and whatever gets the job done is fine. In that case though warnings are not an issue either so where's the problem? In longer lived code the warning plays an important role - it is pointing out bad practice that, in my view, always serves to obscure the intent of the code and always makes maintenance harder. While TMTOWTDI applies on a fine scale, my interpretation of TMTOWTDI is that Perl as a language allows different programming paradigms rather than locking programmers into "one true way" style coding. That is, TMTOWTDI addresses functional versus OO versus procedural and other high level style choices and to a lesser extent choices other languages don't offer like high and low priority operators and use of statement modifiers. TMTOWTDI is largely orthogonal to code maintenance discussions.

This node is not about obfuscation nor about code maintenance. It is more about warning, its significance and about operators which throws it.

The significance of the warning is exactly about code maintenance and obfuscation. In places where the warning doesn't matter such as one liners and deliberately obfuscated code, ignore the warning. In any other context, fix the code. The warning is your friend.

Optimising for fewest key strokes only makes sense transmitting to Pluto or beyond

In reply to Re^3: Situation where warning "Found = in conditional, should be" seems obsolete by GrandFather
in thread Situation where warning "Found = in conditional, should be" seems obsolete by rsFalse

Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":

  • Are you posting in the right place? Check out Where do I post X? to know for sure.
  • Posts may use any of the Perl Monks Approved HTML tags. Currently these include the following:
    <code> <a> <b> <big> <blockquote> <br /> <dd> <dl> <dt> <em> <font> <h1> <h2> <h3> <h4> <h5> <h6> <hr /> <i> <li> <nbsp> <ol> <p> <small> <strike> <strong> <sub> <sup> <table> <td> <th> <tr> <tt> <u> <ul>
  • Snippets of code should be wrapped in <code> tags not <pre> tags. In fact, <pre> tags should generally be avoided. If they must be used, extreme care should be taken to ensure that their contents do not have long lines (<70 chars), in order to prevent horizontal scrolling (and possible janitor intervention).
  • Want more info? How to link or or How to display code and escape characters are good places to start.
Log In?

What's my password?
Create A New User
Domain Nodelet?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others meditating upon the Monastery: (4)
As of 2022-09-29 12:01 GMT
Find Nodes?
    Voting Booth?
    I prefer my indexes to start at:

    Results (125 votes). Check out past polls.