A warning for subs that you declare but then don't use would be really annoying for those who are doing more advanced things behind-the-scenes. I might want to declare a subroutine name, but then define it at run-time.
Indeed in the very same script I had
sub killp;
*killp = DEBUG ? \&_killp_debug : \&_killp_real;
although I bet that many Perl hackers wouldn't regard this as a good practice.
However we already do e.g.
no strict 'refs';
# and
no warnings 'uninitialized';
all the time. A 'used only once' warning as suggested by someone else wouldn't be that bad after all.
I don't run into this problem because I like parens that give perl a bit of extra help with the parsing (and keep maintenance programmers from getting too confused too).
Well, that's to a very large extent a matter of personal preferences, just like so many other things in Perl. I find code having as few parentheses as possible to be best readable. | [reply]
[d/l]
[select] |
I find code having as few parentheses as possible to be best readable.
Depends. There are some situations where parens add
clarity, and there are others where they don't.
Generally speaking, if there's a significant potential
for someone's not having memorized the precedence
table to result in confusion, it's better to include
the parens, but otherwise you can leave them off.
Obviously, different people have different threshholds
for how divergent the precedences in question have to
be before the potential to misread is sufficiently
small to justify leaving off the parens, but I think
in principle most of us can agree that there are some
pairs of operations with a very similar precedence,
in which case the parens add clarity, but there are
other pairs of operators that have such markedly
different precedence that any clarity the parens add
is extremely marginal and not worth the tradeoff. It
becomes a question, then, of where to draw the line.
A good example of the latter scenerio is when you're
using the loose-binding spelled-out logical ops to
join together expressions containing tightly-bound
operators, as in
$foo .= <BAR> or return $foo;.
Nobody with significant Perl experience needs
parens to help them through that one. On the other
end of the scale you can have expressions that include
bitwise operators and other relatively obscure ops
for which many people don't remember the precedence.
In those cases, the parens are a Good Idea.
"In adjectives, with the addition of inflectional endings, a changeable long vowel (Qamets or Tsere) in an open, propretonic syllable will reduce to Vocal Shewa. This type of change occurs when the open, pretonic syllable of the masculine singular adjective becomes propretonic with the addition of inflectional endings."
— Pratico & Van Pelt, BBHG, p68
| [reply]
[d/l] |
There's never any GOOD reason to go leaving parens out. Not on maintained code, anyway.
See the story on nuclear missiles and Perl.. with the mistake being blamed on an ASSUMED precedence order on an operation.
Even in this example use of parenthesis would have given this user the compile time warning he was looking for. Even smarter would be to add argument expections to the prototype:
sub chk_timer( $ );
But programmers like to think they are smarter than that and take risks. So do a lot of American drivers refusing to wear their seatbelts. That's ok, an ego is a precious thing, except in professional circles. If you can't program to protect against yourself, or drive wearing a seatbelt JUST IN CASE, then you have no defence when you look silly (or dead) at the end of the day.
The art of programming is like self defence, mastery of self. I am not perfect.. are you?
| [reply] |
But then your argument is just as valid for the annoying warning about a possible typo when using a package variable only once. Who says, I don't do advanced things behind-the-scenes then?So if Perl warns me in this case, why not when declaring and failing to define a subroutine?
| [reply] |
I don't like that "variable used once" either. If I've declared a variable so that use strict doesn't complain, but I only use it once, I don't want to see a warning. I've seen a lot of code that uses a variable in void context just to get around that warning.
--
brian d foy <brian@stonehenge.com>
| [reply]
[d/l] |