in reply to Re^3: Dereferencing in blessed object
in thread Dereferencing in blessed object

I suggest you always -- as a matter of routine habit -- order your file with functions first and mainline at the end

Whilst that makes sense, it somehow feels wrong.
Probably because I have always written code with the subroutines at the end. I recall it being a bit of a revelation when I realised that it wasn't compulsory to have them at the end!

An alternative is to leave the mainline first but put a bare block around it

That seems very sensible. It's also something that can be applied to existing code relatively easily.

Replies are listed 'Best First'.
Re^5: Dereferencing in blessed object
by eyepopslikeamosquito (Archbishop) on Feb 27, 2021 at 21:26 UTC

    ... I have always written code with the subroutines at the end
    Curiously, 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: 
    use strict;
use warnings;

# mainline--------------------------
mygreeting "world";

# subroutines ----------------------
sub mygreeting {
   my $salutation = shift;
   print "hello $salutation\n";
}

    [download]
    fails to compile: 
    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""

    [download]

    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");

    [download]

    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:

    • Don’t use unnecessary parentheses for builtins and ‘honorary’ builtins (item 4)
    • Call subroutines with parentheses but without a leading & (item 113)

[reply]
[d/l]
[select]

      I think putting subroutines at the end was a requirement of BBC Basic1 which is where my coding started...well, actually it started before that with Shape Tables on an Apple II. Two of them had been purchased by the school the year I started at grammar school - that's a long time ago!

      Until very recently I always used a leading & for subroutines - I didn't realise it was optional generally a bad idea.
      I think I always add parenthesis to user-defined functions so unwittingly follow that style directive.

      Don’t use unnecessary parentheses for builtins and ‘honorary’ builtins

      Is an 'honorary' built-in something that is very common but not part of Perl language?
      Something like fetchrow_array in DBI or get in LWP::Simple.

      I was surprised to see item 122 on the list...
      Don’t use subroutine prototypes
      Surely prototypes, in some circumstances, are extremely useful.

      1 - Incidentally, the BBC Micro turns 40 this year!

[reply]
[d/l]
[select]
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom