[futurebasic] Re: [FB] INCLUDE an INCLUDE

Message: < previous - next > : Reply : Subscribe : Cleanse
Home   : June 1999 : Group Archive : Group : All Groups

From: tedd <tedd@...>
Date: Mon, 14 Jun 1999 16:05:07 -0400
>>> I've always heard it was bad karma to INCLUDE an INCLUDE... If it works
>though, more power to ya. <<
>If someone has thought these same thoughts and can express them articulately,
>I'd like to hear about it. Y'see, my son does includes-within-includes (teeny
>little files, he could just as well consolidate everything & stick in a few
>Labels for navigation) and I'd love to come up with an argument more
>sophisticated than "MUST you do that? It drives me right up the wall!!!!"


The arguments goes "If you don't need that set of functions any where else
in your program, then it's Okay to include that file within another Include
file." However, if at some point you need one of those included/included
functions in a different portion of your program, then you're out of luck.
Or so, I believe. I know that I had problems with it several light years
ago. In  addition, I'm not sure that even the main file can access a
function that is in an included include file -- but I may be wrong.

My rule of thumb is to divide Includes into topics. Such as, I always have
an initialize include (init.INCL) -- wherein all global variables are
initialized; a linked list include (link.INCL) -- wherein all links are
maintained; a draw include (draw.INCL) -- wherein all non-automatically
refreshed drawing takes place. You get the idea.

The point is to make your includes have some commonality with your
functions. I view Includes as something more than just a way to get around
the 32k limit in code. It's part of a programming philosophy of making
things easier to read and maintain. Clearly, an Include file that contains
more Include files does not make for easier reading, maintaining, or
debugging of your program. It's poor programming, IMHO.

My $0.2


<mailto:tedd@...>	               http://sperling.com/