and then, if you can't find "another way", disable the tool.
| [reply] |
I'd rather say, that if a tool, that is beneficial to the whole code, gets in the way of a small task, one should try to find out, whether there might be another way of doing this small task, without disabling the tool, and the benefits associated with its use.
No, that doesn't make sense.
You're going to spend more time (finding out whether there's a way of doing it while keeping your precious "strict" (or "warnings" or something else), for the sake of keeping your tool enabled, and likely to end up with pointless code -- after which chromatic starts nagging you about "synthetic code".
If you're ever adding code just to silence a warning, you're doing it wrong. If you make code more complicated, just so you don't have to temporarely use "no strict", you're doing it wrong. If you're even going to spend time finding out whether you can do any of the above, you're not only doing it wrong, you're also wasting the money of whoever is paying you.
# Bad code:
$foo = ($bar // 0) + 4 if ($var1 // 0) == ($var2 // 0);
# Better code:
no warnings 'uninitialized';
$foo = $bar + 4 if $var1 == $var2;
Feel free to draw some curly braces on your screen if one thinks this "better code" isn't part of some lexical block and is dumb enough to assume I advocate turning warnings off in the entire program. | [reply]
[d/l] |
If you're even going to spend time finding out whether you can do any of the above, you're not only doing it wrong, you're also wasting the money of whoever is paying you.
If you're going to be passing around bareword filehandles, you're supposed to use typeglobs or typeglob references -- its a lesson well worth the time learning, and if he just turned off strict, never would have learned it
| [reply] |
As I've told you (or one of your clones) before, in my first reply, I made it clear I was talking in general terms. But I guess actually reading and understanding a complete paragraph is a bit too difficult for some people.
| [reply] |
