× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



--- "Bartell, Aaron L. (TC)" <ALBartell@taylorcorp.com> wrote:
> <snip>
> Really, we could take this to the extreme and say that every line of code
> is a potential function
> in and of itself that could grow.  So why not avoid the inevitable and give
> every line of code its own subroutine / subproc?
> </snip>
> 
> Are you seriously asking or are you being facetious?

Definitely facetious.

> In some cases the mainline of a program might be 100% composed of
> sub-procedure calls.  It makes it a lot easier to read and get a concept of
> what is going on.  Take a look at some of Nathan Andelin's(Relational Web)
> code sometime; you have no idea what it is doing behind the scenes, but you
> know what the program is accomplishing as a whole without hours upon hours
> of research.

Where do I find Nathan's Relational Web code?

Note, again (for the third time), I am speaking against turning one-line 
functions (i.e., SETON
LR) into their own sub-whatevers.  

PLEASE, EVERYONE, READ THAT LAST STATEMENT AGAIN, JUST TO BE CLEAR.

I have written a LOT of mainlines that do nothing but execute subroutines.  I 
rely heavily on
modularizing code this way.  And I look forward to the day that I can make it a 
standard in this
shop to use & rely on procedures in service programs.

BUT, I will not ever write a sub-whatever that only performs one opcode.  And 
any that cross my
maintenance activities will be summarily executed, errr, deleted.

- Dan


__________________________________________________
Do you Yahoo!?
Yahoo! Shopping - Send Flowers for Valentine's Day
http://shopping.yahoo.com

As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.