in reply to Re: Changing Local Variable Out of Context
in thread Changing Local Variable Out of Context

In general it's best practice in any programming language to minimize scope, and often, it's helpful to initialize. A var name just *appearing* in a sub, with no local declaration, or not passed in, is at best confusing, and at worst a disaster. It might be defined "miles away" from the sub. The poor bloke maintaining it years from now may have a devil of a time finding it, AND what if it's defined in many places?

bareblocks help minimize scope, I think about using them whenever I program. Many programmers scope at the "sub" level, but it helps to scope even deeper- within a sub. In general my rules for tite code include:

a Var's lifetime should be never preceed, or outlast, its usefulness Declare at the last possible moment; go out of scope at the earliest
Here where I want to get an XML value from a file I might use

my $XMLval=''; { open X,'myfile'; my @X= grep /<myfavoritetag>/,<X>; last unless @X; $X[0] =~ s/<\/?[^>]+>//g; # shoot the tag and end tag.. $XMLVal=$X[0]; } # here we have $XMLval ready to go , all cleaned up, # and @X is out of scope , # so no worries about it anymore or any other gobbltygook # in the braces

I could have, and used to, just let @X "hang around" until the sub exited. After 30 years in Perl though, I'm much more conscious of scope and it's hazards.

It also makes intent clearer- when leaving the bareblock, there is no ambiguity about if @X might be needed, or used, subsequently. Some bloke looking at my code won't have to try to "figure that out" later.

But worst of all are global vars. To me, using those is like depending on a "side effect". As a min, declare them in main , but where needed, PASS THEM in as a ref or by value.

Just some musings about scope...

Replies are listed 'Best First'.
Re^3: Changing Local Variable Out of Context
by NERDVANA (Priest) on Jun 16, 2023 at 17:23 UTC
    But worst of all are global vars. To me, using those is like depending on a "side effect". As a min, declare them in main , but where needed, PASS THEM in as a ref or by value.

    Using a global variable as a variable in a procedural manner to store temporary information can be bad, but globals have their place, and especially in perl with the 'local' keyword that allows them to act like environment variables during the scope of a function.

    Also, I'm a fan of end-user freedom, so in all my modules I declare my package variables using 'our' instead of 'my', because it's not for me to judge whether some user of my module should override that or not. That would save the OP from jumping through the hoops of PadWalker just to customize some bit of behavior. (whether a better approach is possible for them is a different argument)

Re^3: Changing Local Variable Out of Context
by karlgoethebier (Abbot) on Jun 13, 2023 at 21:12 UTC
    «But worst of all are global vars…using those is like depending on a "side effect"…where needed, PASS THEM in as a ref…»

    You contradict yourself.

    «The Crux of the Biscuit is the Apostrophe»

      «But worst of all are global vars…using those is like depending on a "side effect"…where needed, PASS THEM in as a ref…» <<You contradict yourself.>>

      No, I dont.

      A var can be global (in main) AND its in the namespace in subs. But even though its scoped globally, for clarity it CAN BE passed in. The fact that it's referenced, or its value is passed in, doesnt change the fact that its scope is global.

      mysub( $::Var )
      Doesn't mean that $::Var is no longer GLOBAL.

      There is no contradiction. Look for value in contributions, not fault.

        I talk about side effects.

        «The Crux of the Biscuit is the Apostrophe»

Re^3: Changing Local Variable Out of Context
by cavac (Prior) on Jun 14, 2023 at 14:55 UTC

    But worst of all are global vars. To me, using those is like depending on a "side effect".

    Global variables have their use cases. In Perl, there are probably more than you think. STDERR for example.

    Global variables can be even more important with other programming languages and use cases. For example in Arduinos and other microcontroller applications. When you only got 1024 RAM bytes to work with, you want to be efficient and not "waste" any on unneeded OO stuff.

    PerlMonks XP is useless? Not anymore: XPD - Do more with your PerlMonks XP