... I have always written code with the subroutines at the endCuriously, I've always done the reverse, perhaps because in C you must declare a function before calling it, and I wanted to avoid the tedious duplication of writing forward declarations for my locally defined C functions called from main. Even in Perl, order matters, for example:
fails to compile:use strict; use warnings; # mainline-------------------------- mygreeting "world"; # subroutines ---------------------- sub mygreeting { my $salutation = shift; print "hello $salutation\n"; }
String found where operator expected at g1.pl line 5, near "mygreeting + "world"" (Do you need to predeclare mygreeting?) syntax error at g1.pl line 5, near "mygreeting "world""
because the compiler is yet to see the mygreeting subroutine definition. Though you can fix with the compiler's predeclare mygreeting suggestion, or by hoisting the mygreeting subroutine definition to the top of the file, I prefer to avoid these sorts of compilation glitches simply by following a simple rule: "always call user-defined subroutines with parens". Here the parens give the compiler a strong hint that mygreeting is a subroutine, even though it is yet to parse its definition. That is, this compilation error is easily remedied simply by adding parens to the call:
mygreeting("world");
As a matter of style, some folks find the code easier to read when user-defined functions are always called with parens and built-in functions are always called without parens ... I see Perl Best Practices endorses this style via:
In reply to Re^5: Dereferencing in blessed object
by eyepopslikeamosquito
in thread Dereferencing in blessed object
by Bod
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |