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

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

by Wassercrats
on Sep 15, 2004 at 04:04 UTC ( #391066=note: print w/ replies, xml ) Need Help??


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

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".


Comment on Re^5: Global variable vs passing variable from sub to sub
Re^6: Global variable vs passing variable from sub to sub
by dragonchild (Archbishop) on Sep 15, 2004 at 13:37 UTC
    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.

        Planning takes time and time is money. If I could get by with less planning, I will....Never count on plans. Code should be flexible.

        I couldn't agree more. It's useless to attempt to modularize anything until you're working on your code (by modularizing, I include putting code into functions or separate modules). So, don't modularize your code until your working on it. If you see some repeating code, or code you might want to use elsewhere, modularize it then so you don't repeat yourself later. Repeating code is what takes time and money, especially in the maintanence costs. Smart coding saves money.

        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.

        Absolutely no luck is needed if you create functions or modules to access the data from somewhere else. It does prevent some boneheaded errors, though, caused by accidentily using a variable with the same name twice, so in that way, I guess it makes you lucky.

        I don't think much about making each routine suitable for a module...

        Again, I could not agree with you more. No module should every be a 100% solution to any problem. Every situation is unique and every script is unique. However, if you could put about 80% of the code into a module, that's where life becomes easy.

        Let's think about an example module: LWP::Simple. It would be impossible to write a module that could access all the different sites on the Internet with a different function call for each one (the thought of getprint_google just makes my head spin). What LWP::Simple does is save you from having to write Perl networking code by allowing you to write my $pm = getprint("http://www.perlmonks.org"); instead. Think what it would be like to write a web client or even WWW::Mechanize without LWP. The beauty of modularized code is that once you have a great API, you never have to do it again.

        Planning takes time and time is money.

        On its face, this is a true statement. However, the costs of not planning are almost universally higher than the costs of planning.

        Or, rather, you will do all the planning needed for a given project at some point or another. Let me explain.

        According to the standard project lifecycle, a given project will need to go through the following stages:

        1. Requirements gathering
        2. Requiremens analysis
        3. Architectural analysis
        4. High-level design (API decomposition, for example)
        5. High-level design verification
        6. Low-level design (This function does X, that function does Y)
        7. High-level design verification
        8. Coding
        9. Code verification
        10. System verification
        11. Roll-out

        Maintenance is a repetition of the above steps, but with a slightly different focus at each one. For example, architectural analysis goes from analysing what you'd like to analysing what you can get away with.

        Now, most "authorities" state that a given project should go through those steps in that order. Most real-world project, however, don't. Instead, they lump most of those activies in the Coding bucket. Instead of analysing requirements, someone starts coding and bitches about the poor requirements. Instead of architectural analysis, the coder just uses whatever s/he feels comfortable with.

        What ends up happening is that a given project will go through those steps, just without the benefit of being able to change their mind about previous choices. This means that what turn out to be poor architectural choices cannot be altered without significant cost.

        There is a reason why over two thirds of all projects started in corporate America fail. They fail because too much money has been sunk into coding by the time it's realized that the architecture or requirements are flat-out wrong. So, the company loses often 2-5 million dollars and 6-12 months. Why? It wasn't over-planning ...

        because if you end up needing that data once you're working on a different part of the script

        That's what orthogonal coding is for. I wrote about this in Maintainable code is the best code. Maintenance isn't just for when you have released a project. Maintenance is when you have finished a requirement and are going on to the next. If you have a set of functions that are the accessors for a given data structure, then any piece of code can call those functions and access that data structure. If you need to change the data structure, you need to change only those accessor functions. Nothing else needs to know that the data structure changed! "A stitch in time saves nine."

        I don't think much about making each routine suitable for a module

        I think this demonstrates your lack of experience in the industry. I'm not being mean. I work with several people who have less than 2-3 years under their belt. They're still very wet behind the ears. Writing modular code as a habit is a paradigm shift, and not a small one. That's perfectly fine. Every single programmer wrote their first program at some point, and I don't think any first program was ever modular. I know mine wasn't. It took me several years to understand why I wanted to do this modular crap. But, I chose to change my habits. Not because someone told me to, though that helped. Not because I had an epiphany. I chose to change because I found it easier to work that way. Less time was spent tracking down the same bug, because I knew I fixed it in the one place it could occur. That was my reason for doing things in a modular fashion.

        Later, I found it made things easier for me to code, by allowing me to focus on higher-level abstractions vs. having to constantly juggle a million things in my head. I'm not a very smart man - I can't keep more than 5 or 6 things in my head at once before I start to get a headache. So, I work in a way that fits my limitations.

        I also learned patience. I'm currently working on a log-analysis website. Writing it modularly does take more time.

        But, I was able to benefit from modular code I used in another project so that I didn't have to write the database accessor code or the web-application framework or the main templating framework. It was already done and in a way that was reusable. So, even though I don't have many of the pages done, and those that are up aren't finished, I'm actually further ahead than I would have been if I had started from scratch. Plus, I know that half the code is already tested, so my verification burden is smaller than it would have been. If I find a bug, I know that it probably isn't in the code I am reusing, because that code is more likely to be bugfree.

        ------
        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^6: Global variable vs passing variable from sub to sub
by Steve_p (Priest) on Sep 15, 2004 at 16:54 UTC

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

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (4)
As of 2014-12-27 01:15 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    Is guessing a good strategy for surviving in the IT business?





    Results (176 votes), past polls