Beefy Boxes and Bandwidth Generously Provided by pair Networks
Do you know where your variables are?
 
PerlMonks  

Re^3: Global variable vs passing variable from sub to sub

by Wassercrats
on Sep 14, 2004 at 21:32 UTC ( #390985=note: print w/ replies, xml ) Need Help??


in reply to Re^2: Global variable vs passing variable from sub to sub
in thread Global variable vs passing variable from sub to sub

I won't read through the tutorials to learn what that last line does. I recognize all the operators, but can't be sure what it does without looking stuff up. The use of "&&" confuses me. It looks like some boolian structure that I used to know how to use, or maybe it's an ordinary logical "and", but I'd like to see parentheses in that case because I never remember the order of operations of things.

I recognized the hash, but I'm unsure about the the use of "exists". I guess it's being used for the 1 or 0 value, but I don't think that's how it's usually used. I wouldn't use hashes when teaching something not related to hashes. I've only used them once when I wrote Varstructor, which had to parse code that might contain hashes, and maybe another time for that duplicate elimination trick.

In the second block of code, I just didn't get the point. Maybe I didn't try hard enough, but a better explanation would have helped.

No matter what code you use in an example, it helps to explain what it does.

...*any* single one of those 11,000 lines can modify that global value. Therefor, when your global has the *wrong* value, you have problems finding it, because you must examine 11,000 lines of code.

After I posted that reply I realized that might the person's point, but he mentioned having to step through the code with a debugger, which wouldn't be necessary. Is it really so hard to search the code for the variable in question? Even Wordpad, which I'm still using for now, could do that. With globals, you don't have to check to see if you passed the value on to another routine. You merely search for a variable by name.

As I mentioned in another thread, if you change plans and want to call a variable that was lexically scoped a few routines ago, things get complicated.

I find the arguments in this thread to be lacking substance. The effort it takes to properly scope variables, which often requires a different code structure, outweighs the problems I've encountered using globals. Globals mean less planning ahead, EASIER debugging, and, using the definition of "safe" that people have used with me, safer code.


Comment on Re^3: Global variable vs passing variable from sub to sub
Re^4: Global variable vs passing variable from sub to sub
by Rhys (Pilgrim) on Sep 14, 2004 at 22:52 UTC
    Wassercrats,

    While I agree that debugging code - particularly code that you're still familiar with - is usually just as easy/difficult with or without globals, the Real Reason that I have discovered that people scope things and use 'my' are as follows:

    People use 'my' along with 'use strict' to make sure typos don't get taken seriously. Auto-vivification is cool in some contexts, but I just plain don't see the difference between $options{debug} and $optoins{debug}. Perl does, though, if %options is declared and I have 'use strict' enabled. This has saved me hours of debugging time chasing typos.

    People use local variables in subs because they like to turn them into modules that get used in other programs, and sometimes those other programs already have another variable - used for something else - by the same name. I always use $mib, $sess, $var, $vb, and $vl in my SNMP-related scripts. Straight from the man page for SNMP.pm. This would be a problem if I didn't do a lot of my code in modules (along with 'use strict', 'my', etc. etc.).

    I don't find that having local vs. global variables has helped my debugging any, though (not that I use proper debugging techniques, AFAIK).

    --J

      You said "...I just plain don't see the difference between $options{debug} and $optoins{debug}."

      I've had bugs like that. I don't know what would take more time, debugging such bugs or initializing every variable. The former is rare. The latter would have to be done all the time.

      Luckily, I have VarStructor 1.0 to list all my variables so I could see if I made such a typo. And there is no module that does a better job listing the variables within a script. Diotalevi thought he had a contender, then demerphq thought he had one. Bugs were brought to their attention shortly thereafter. If the only contribution VarStructor 1.0 has made to the Perl community is to highlight the bugs in competing modules, and get them repaired, it was worth it. And now that the bugs are fixed in the competing modules, VarStructor 1.0 STILL kicks their ass.

      I deleted the VarStructor 1.0 code from Perlmonks a few days ago, so I guess you all have one more reason to use strict than I do. This isn't a local variable issue anyway, incase nobody noticed.

      You said "People use local variables in subs because they like to turn them into modules that get used in other programs..."

      I'm not such a people.

        I'm not such a people.

        Ok. No-one says you have to do it. We're simply explaining why we choose to 'use strict', initialize every variable, scope things as tight as possible, and all that other crap.

        I don't know what would take more time, debugging such bugs or initializing every variable. The former is rare. The latter would have to be done all the time.

        Personally, I find it a lot easier to declare every variable immediately, because it helps me keep track of things. That may not be a concern of yours, so my experiences may not have relevance to you. I also prefer to have Perl determine when I typo something vs. running a separate program. Again, different strokes.

        I also find it helpful to scope variables as tightly as possible, because it helps me understand the code I just wrote. I choose to keep as few details in my head as possible. This requires me to organize my code in a certain way, so that I can immediately understand the code I wrote in a glance. Again, I am not saying that I have "The Holy Writ"(tm) when it comes to coding styles. I'm only describing those practices that help me, personally, and explaining why I recommend them to people who ask.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

        I shouldn't have to say this, but any code, unless otherwise stated, is untested

Re^4: Global variable vs passing variable from sub to sub
by Pragma (Scribe) on Sep 15, 2004 at 03:10 UTC
    I won't read ...
    Ah, Wassercrats. We know.
Re^4: Global variable vs passing variable from sub to sub
by Anonymous Monk on Sep 15, 2004 at 03:52 UTC
    I find the arguments in this thread to be lacking substance

    And then all you provide are arguments like

    The effort it takes to properly scope variables, which often requires a different code structure, outweighs the problems I've encountered using globals.

    with no explanation whatsoever about what you find so difficult about scoping variables.


    I'll summarize everyone else's arguments into a form which contains the same amount of "substance" (You keep using that word... I do not think it means what you think it means--Inigo Montoya) as your posts: Scoping variables takes no additional effort and it eliminates one potential source of bugs.

      Who are you?

      merlyn said "Both 'passing around' and 'global variables' are a signs of a misdesign....provide a higher-level interface that don't need to expose that variable...create a module..."

      That sounds like a script using local variables might require a different structure. Obviously, scoping a variable to a certain block means it shouldn't be needed outside that block (or "region"), and that takes more planning, and some luck.

      Another obvious bit of effort comes from declaring variables, and even by using "my".

        and that takes more planning,

        Programming is a profession built around planning. I would be hesitant to complain that a feature many people depend on should be scrapped because it requires more planning.

        and some luck.

        I'm curious as to where you feel luck enters into the programming arena. It hasn't been my experience that luck plays a factor at all.

        ------
        We are the carpenters and bricklayers of the Information Age.

        Then there are Damian modules.... *sigh* ... that's not about being less-lazy -- that's about being on some really good drugs -- you know, there is no spoon. - flyingmoose

        I shouldn't have to say this, but any code, unless otherwise stated, is untested

        merlyn said "Both 'passing around' and 'global variables' are a signs of a misdesign....provide a higher-level interface that don't need to expose that variable...create a module..."

        merlyn was explaining the Too many parameters code smell. If you are passing the same parameters around constantly from function to function, then they belong together in a single module or object. The quote that seems most appropriate is:

        TooManyParameters is often a CodeSmell. If you have to pass that much data together, it could indicate the data is related in some way and wants to be encapsulated in its own class. Passing in a single structure data that belongs apart doesn't solve the problem. Rather, the idea is that things that belong together, keep together; things that belong apart, keep apart;....

        That sounds like a script using local variables might require a different structure.

        Not really. If you are properly scoping your variables, it would require very few changes to the structure of your script. What you would do is tease out the reusable or highly related portions of the code into separate modules.

        Obviously, scoping a variable to a certain block means it shouldn't be needed outside that block (or "region"), and that takes more planning, and some luck.

        Again, not really. If you notice that you are repeating yourself in your code needlessly, then separate it out. If the repeat is pretty narrow in scope, adding a new function is all that maybe needed. If its more complex, or you can use the code elsewhere, a module may be needed. This involves little planning and very little luck. Then, getting the data you need elsewhere would require a function call.

        Another obvious bit of effort comes from declaring variables, and even by using "my".

        Well, typing three characters ("my ") does involve some effort, but its pretty minimal. The benefits, however, in having scoped code, such as: the ability to test your code in an automated manner; reusability of code; the fact that smaller pieces of code are easier to understand, debug, and fix; etc., are much more cost effective than the alternative.

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://390985]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others contemplating the Monastery: (3)
As of 2014-09-23 02:22 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (210 votes), past polls