Question re calling subroutines
in [Perl]
|
Prev: Does this match any number or just single digit ones?
Next: FAQ 6.24 How do I match a regular expression that's in a variable?
From: Tad McClellan on 9 Aug 2010 16:00 Keith Thompson <kst-u(a)mib.org> wrote: > "Uri Guttman" <uri(a)StemSystems.com> writes: >>>>>>> "H" == HerbF <HerbF(a)earthlink.net> writes: >> H> I typically call subroutines without using parenthesis, e.g., &abc;. I >> H> have one routine where I pass variables and I call it as: >> >> that is poor perl code and perl4 style. don't use & for sub calls as it >> has side effects you may not know about. read perldoc perlsub for more. >> >> H> Should I be using parenthesis at the subroutine, i.e., >> >> H> sub abc (A,B,C) {...} >> >> that has nothing to do with parens at the sub call itself. perl doesn't >> support named arguments like you have there so it won't do any good to >> try it. >> >> sub calls should be made with parens is the common style rule and not >> with &. > > I tend to omit parentheses in many cases where they're not necessary. > For example, I might write: > > sub Foo; > ... > my $x = Foo 42; # rather than Foo(42) > ... > sub Foo { > my($arg) = @_; > return $arg + 1; > } > > Would you consider this to be a bad habit? I would consider that a bad habit with regard to user-defined functions. I usually omit parens for builtin functions. I just object to the need for the forward declaration, which is not needed if you use parens in the function call. A weak reason, I'll admit. -- Tad McClellan email: perl -le "print scalar reverse qq/moc.liamg\100cm.j.dat/" The above message is a Usenet post. I don't recall having given anyone permission to use it on a Web site.
From: Keith Thompson on 9 Aug 2010 22:38 "Uri Guttman" <uri(a)StemSystems.com> writes: >>>>>> "KT" == Keith Thompson <kst-u(a)mib.org> writes: > KT> I tend to omit parentheses in many cases where they're not necessary. > KT> For example, I might write: > > KT> sub Foo; > KT> ... > KT> my $x = Foo 42; # rather than Foo(42) > KT> ... > KT> sub Foo { > KT> my($arg) = @_; > KT> return $arg + 1; > KT> } > > that only works if you declare Foo before you call it. perl can't tell > if a bareword is a sub if it hasn't seen it before unless you use parens. Which is why I always predeclare all my subroutines. > look at these examples which show why always using parens is a good thing: > > perl -we 'sub foo {print "hello\n" } ; foo' > hello > > perl -we 'foo; sub foo {print "hello\n" }' > Unquoted string "foo" may clash with future reserved word at -e line 1. > Useless use of a constant in void context at -e line 1. > > perl -we 'foo(); sub foo {print "hello\n" }' > hello > > KT> Would you consider this to be a bad habit? (I don't use "&" on > KT> calls, and I've broken my previous habit of using prototypes.) > > yes, as i show above. btw, predeclaring also works for exported subs > from a module. still i use parens. only with protoyped subs that need to > look like builtins might i skip the parens. The examples show that the parentheses are necessary if subroutines aren't predeclared. > KT> I know that parentheses are necessary for something like: > > KT> print "Foo 42 = ", Foo(42), "\n"; > > KT> because without them the "\n" is passed to Foo, not to print. > > that is a precedence issue, not a predeclared one. if Foo were > predeclared with a prototype of a single arg, the parens wouldn't be > needed and it would work. Right, but I've been persuaded that prototypes (at least as they currently exist in Perl 5) are generally not as good an idea as I once thought. Still, I can certainly see that a policy of using parentheses for all subroutine calls makes for more consistent code, and relieves you of worrying about whether you can get away with omitting them or not. I'll give it some thought. Thanks. -- Keith Thompson (The_Other_Keith) kst-u(a)mib.org <http://www.ghoti.net/~kst> Nokia "We must do something. This is something. Therefore, we must do this." -- Antony Jay and Jonathan Lynn, "Yes Minister"
From: Uri Guttman on 9 Aug 2010 23:20 >>>>> "KT" == Keith Thompson <kst-u(a)mib.org> writes: KT> "Uri Guttman" <uri(a)StemSystems.com> writes: >>>>>>> "KT" == Keith Thompson <kst-u(a)mib.org> writes: KT> I tend to omit parentheses in many cases where they're not necessary. KT> For example, I might write: >> KT> sub Foo; KT> ... KT> my $x = Foo 42; # rather than Foo(42) KT> ... KT> sub Foo { KT> my($arg) = @_; KT> return $arg + 1; KT> } >> >> that only works if you declare Foo before you call it. perl can't tell >> if a bareword is a sub if it hasn't seen it before unless you use parens. KT> Which is why I always predeclare all my subroutines. and that is a waste of pixels as well. why do more work than you need to? i review code for my recruiting business and i would downgrade any code with predeclared subs. putting the subs before the calls makes for a hard to read file. i put low importance subs at the bottom and order the rest is some form of logical top down. this allows for easier understanding of the code as you read it. and that means predeclaring won't work. remember code is for people, not computers. and code is for OTHER people, not yourself. >> look at these examples which show why always using parens is a good thing: >> >> perl -we 'sub foo {print "hello\n" } ; foo' >> hello >> >> perl -we 'foo; sub foo {print "hello\n" }' >> Unquoted string "foo" may clash with future reserved word at -e line 1. >> Useless use of a constant in void context at -e line 1. >> >> perl -we 'foo(); sub foo {print "hello\n" }' >> hello >> KT> Would you consider this to be a bad habit? (I don't use "&" on KT> calls, and I've broken my previous habit of using prototypes.) >> >> yes, as i show above. btw, predeclaring also works for exported subs >> from a module. still i use parens. only with protoyped subs that need to >> look like builtins might i skip the parens. KT> The examples show that the parentheses are necessary if subroutines KT> aren't predeclared. and predeclaring is another bad habit. KT> I know that parentheses are necessary for something like: >> KT> print "Foo 42 = ", Foo(42), "\n"; >> KT> because without them the "\n" is passed to Foo, not to print. >> >> that is a precedence issue, not a predeclared one. if Foo were >> predeclared with a prototype of a single arg, the parens wouldn't be >> needed and it would work. KT> Right, but I've been persuaded that prototypes (at least as they KT> currently exist in Perl 5) are generally not as good an idea as I KT> once thought. good, then you are capable of learning and improving your style! :) KT> Still, I can certainly see that a policy of using parentheses for all KT> subroutine calls makes for more consistent code, and relieves you of KT> worrying about whether you can get away with omitting them or not. KT> I'll give it some thought. s/some/a lot of/ ; :) uri -- Uri Guttman ------ uri(a)stemsystems.com -------- http://www.sysarch.com -- ----- Perl Code Review , Architecture, Development, Training, Support ------ --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com ---------
From: Ben Morrow on 9 Aug 2010 23:51 Quoth "Uri Guttman" <uri(a)StemSystems.com>: > >>>>> "KT" == Keith Thompson <kst-u(a)mib.org> writes: > > KT> "Uri Guttman" <uri(a)StemSystems.com> writes: > >>>>>>> "KT" == Keith Thompson <kst-u(a)mib.org> writes: > KT> I tend to omit parentheses in many cases where they're not necessary. > KT> For example, I might write: > >> > KT> sub Foo; > KT> ... > KT> my $x = Foo 42; # rather than Foo(42) > KT> ... > KT> sub Foo { > KT> my($arg) = @_; > KT> return $arg + 1; > KT> } > >> > >> that only works if you declare Foo before you call it. perl can't tell > >> if a bareword is a sub if it hasn't seen it before unless you use parens. > > KT> Which is why I always predeclare all my subroutines. > > and that is a waste of pixels as well. why do more work than you need > to? i review code for my recruiting business and i would downgrade any > code with predeclared subs. Well, apart from anything else it moves errors from runtime to compile time, which is always a good thing. fop(); sub foo { 1; } will compile just fine, sub foo; fop; sub foo { 1; } will give a strict error at compile time. > putting the subs before the calls makes for > a hard to read file. i put low importance subs at the bottom and order > the rest is some form of logical top down. this allows for easier > understanding of the code as you read it. and that means predeclaring > won't work. No it doesn't. Predeclarations of the form sub foo; or use subs qw/foo/; at the top of the file work just fine, no matter where the body of the sub is. FWIW I always avoid calling subs with () when I can, though I'm no longer as convinced as I was that it's a good idea :). Perl's bareword parsing is frankly terrifying once you understand what it actually does. Ben
From: Uri Guttman on 10 Aug 2010 01:27
>>>>> "BM" == Ben Morrow <ben(a)morrow.me.uk> writes: BM> Quoth "Uri Guttman" <uri(a)StemSystems.com>: >> and that is a waste of pixels as well. why do more work than you need >> to? i review code for my recruiting business and i would downgrade any >> code with predeclared subs. BM> Well, apart from anything else it moves errors from runtime to compile BM> time, which is always a good thing. true in general. but then we would all be using prototypes! :) >> the rest is some form of logical top down. this allows for easier >> understanding of the code as you read it. and that means predeclaring >> won't work. BM> No it doesn't. Predeclarations of the form BM> sub foo; BM> or BM> use subs qw/foo/; BM> at the top of the file work just fine, no matter where the body of the BM> sub is. i know about those and i consider those predeclarations too. i even mentioned exporting subs which does the same thing. more text than is needed and noisy IMO. BM> FWIW I always avoid calling subs with () when I can, though I'm no BM> longer as convinced as I was that it's a good idea :). Perl's bareword BM> parsing is frankly terrifying once you understand what it actually does. join the club! uri -- Uri Guttman ------ uri(a)stemsystems.com -------- http://www.sysarch.com -- ----- Perl Code Review , Architecture, Development, Training, Support ------ --------- Gourmet Hot Cocoa Mix ---- http://bestfriendscocoa.com --------- |