Re: gnat310p on NT

[dewar@merv.cs.nyu.edu (Robert Dewar)]

David Hoos says

<<This is not a gnat problem at all (except to the extent that AdaGIDE is
distributed with gnat), but only with AdaGIDE.  I have experienced the same
problem, but only with code written by others, for I fervently believe that
any code more than a few hundred lines in a file needs to be restructured.

For example, the bodies of subprograms and/or tasks can (should IMHO) be
made separates.
>>


I see no reason for such small limits on file sizes, and there are often
good reasons for packages being a few thousand lines long. There is really
no need to fragment things into lots of separate files just for the sake of
keeping file sizes small. As long as file sizes are compatible with the
style of development, e.g. don't take too long to compile, are suitable for
editing by one person, and are readable and organized, the fetish that says
that any long file is bad seems as misguided as the fetish that any goto
is misguided.

Note in particular that if you have a large case statement, the language
provides no way of abstracting the strucutre into smaller files anyway


Note also that the point that individual *proicedures* as opposed to files
should be kept short is a separate issue, but here too we run into the issue
of theinability to abstract case statements.

By the way, note that David's rule would mean that a 2 million line program
was committed to being chopped up into some 10,000 files. In my experience,
this kind of level of fragmentation is NOT helpful in large projects.

A good question to ask in response to this position (which is not unusual)
is *why* it is a good idea to keep files this small.

As I say, the conditions vary. In the case of the Realia COBOL compiler,
the code generator was a single 35,000 line file. Not because, contrary
to typical uninformed opinion, COBOL has no nice way of breaking things up
into multiple files, but because only one person ever worked on this file
(me) and it took only 20 seconds to compile on a slowish (386 25 MHz) PC
which was quite acceptable.

But if you have lots of people working on a project, you definitely want to
keep files at an approipriate granularity so people do not step on one
anothers toes too much.