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

[Wassercrats]

This node falls below the community's threshold of quality. You may see it by logging in.

[dragonchild]

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.

[Steve_p]

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.