Beefy Boxes and Bandwidth Generously Provided by pair Networks Bob
laziness, impatience, and hubris
 
PerlMonks  

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

by Anonymous Monk
on Sep 15, 2004 at 03:52 UTC ( #391063=note: print w/ replies, xml ) Need Help??


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

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.


Comment on Re^4: Global variable vs passing variable from sub to sub
Re^5: Global variable vs passing variable from sub to sub
by Wassercrats on Sep 15, 2004 at 04:04 UTC

    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

        Planning takes time and time is money. If I could get by with less planning, I will.

        You need luck when combining all code that requires a given piece of data into a single, scoped block, or region, because if you end up needing that data once you're working on a different part of the script (things like that come up in the real world), things can get messy.

        Never count on plans. Code should be flexible. I don't think much about making each routine suitable for a module, but I'm always able to easily access the data I need because I keep data in global variables.

      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://391063]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others exploiting the Monastery: (8)
As of 2014-04-19 05:55 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    April first is:







    Results (478 votes), past polls