http://qs1969.pair.com?node_id=11128100


in reply to Situation where warning "Found = in conditional, should be" seems obsolete

You need to fill up the character hopper on your keyboard so you can be more extravagant and expressive with your code. If this is code from a golf competition sure, do nasty stuff, but suck it up when things grump at you. If this is code for any other purpose take the time to write clear maintainable code.

And don't bother with the "time it takes to type" argument. In writing, reading and replying to this thread you have already used more time than you will ever save in keystroke time writing obfuscated code instead of maintainable code. Actually, you will save more time just in being able to understand what you wrote more quickly in the future (say, ten minutes from when you wrote it) than you lose by spending more time typing.

And in case you think that one complicated line is easier to understand than several shorter lines, especially where important stuff is at the end of the line, then you would be wrong because it isn't true despite what you might wish.

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

Replies are listed 'Best First'.
Re^2: Situation where warning "Found = in conditional, should be" seems obsolete
by rsFalse (Chaplain) on Feb 08, 2021 at 22:01 UTC
    Hello.
    I will spend (waste?) more time for answer this thread. You may not interpret that code as obfuscated or intentionally obfuscated. 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).
    This node is not about obfuscation nor about code maintenance. It is more about warning, its significance and about operators which throws it.
      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
        Thanks for explanation and suggestions!