Re: where do you put your subs

Personally, I like the 40,000 foot view of things, and I like seeing the 40,000 foot view of things when I'm working on someone else's code. So, I like to see the main logic first. Subroutines, to me, are abbreviations, or replacements. They say "I'm not really an operation, but a link to a series of operations." They're shortcuts, abbreviations, macros, etc. (I'm going to get killed for that statement.)

So, I've got my actual logic flow right there, for everyone to see. It's got a bunch of these 'links' to groups of operations. If I want to see a subroutine definition being used in the top level, I don't want to go far. So, all the top-level subroutines are first, in order of invocation. Then, the next level, etc. At some point, I just start chucking things into modules.

That's just my thought. I understand demerphq's view on things, wanting to remove unintended side-effects. But, in my mind, that's reverting to the shotgun we all want to use. If he feels he needs the shotgun, that's fine. I personally feel that I know what each and every one of my variables do, and where its scope is, so I don't need the shotgun.

I so rarely declare file-scoped lexicals that, when I do, it's for the express purpose of creating a file-scoped global. *gasps from the audience* Globals, just like "goto LABEL", have their purpose. But, that's another node.

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

Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

Comment on Re: where do you put your subs

Replies are listed 'Best First'.
Re: Re: where do you put your subs by lachoy (Parson) on Mar 08, 2002 at 15:04 UTC
I agree with this sentiment. IME most of the time I do not need to understand every nuance of how a script works -- implementation details. (Not that they're not important, but most of the time I don't care since, depending on the author, someone has already thought about the problem longer than I have.) So why should I have to plow through all the subroutines to get to the interesting part, the logic that binds them all together? And properly named subroutines should eliminate the need to read a routine just to find out what it does -- for instance, I'd probably have to see what a routine `sortev` does but not `sort_by_estate_value`. Chris M-x auto-bs-mode	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re: Re: where do you put your subs
by lachoy (Parson) on Mar 08, 2002 at 15:04 UTC

I agree with this sentiment. IME most of the time I do not need to understand every nuance of how a script works -- implementation details. (Not that they're not important, but most of the time I don't care since, depending on the author, someone has already thought about the problem longer than I have.)

So why should I have to plow through all the subroutines to get to the interesting part, the logic that binds them all together? And properly named subroutines should eliminate the need to read a routine just to find out what it does -- for instance, I'd probably have to see what a routine sortev does but not sort_by_estate_value.

Chris
M-x auto-bs-mode

[reply]
[d/l]
[select]