Re: Ada95 tutorials with sample code.

[Sven Nilsson <emwsvni@emw.ericsson.se>]

Howdy

I'm replying to my own entry here to try and recap some of the things
thats been said. No flaming at all as far as I can see, thank you very
much people!

Most people seem to agree that the use-clause can be a dangerous thing,
but there are voices raised in it's defence:

1. If you write/design your code properly, the use-clause won't be a
problem and will make the program easier to read and maintain.
2. Standard things like Text_Io and Strings should be known to most
Ada-users and in that case a use-clause can be used safely.
3. Using full names means the code will be less readable (this is noted
in the paper "In defence of the use clause" available at
http://www.adalog.fr/publica2.htm and is consistent with what I know of
readablility index and such things (I'm a teacher at heart))

All of these are good solid reasons to use "use", but I do not agree
with them.
The first one would be nice if it worked, but in my experience people
don't think before they do. As I said in my last post, I work in big
projects with a lot of people working on the same code in different
teams, trusting that everyone has the same view of what is proper design
is bordering on stupidity. "Trust is good, control is better" as the old
saying goes.
The second one should be very true indeed. My example in the other post
(with TIO) is pretty stupid, really. BUT clever chaps tend to override
standard things like text_io and strings to add little extra features.
Like Ted I'm often called in to  figure out why things don't work and
I've actually had a case where a badly implemented debug-text_io was the
whole problem...
The third statement is probably the hardest to argue with. Having spent
the last three years reading and writing Ada-code using full names, I've
gown pretty used to "filtering" out the prefixes until I need them, but
as a beginner the code always seemed horrible complicated. That's a
problem...

Other notes that I feel should be pointed out again is

4. The option of "use type", which I agree can be VERY usefull on
occasion.
5. Using "use" in the procedures/functions where it is really needed.

Number 5 is perhaps the way to go. If we can keep our methods (to use a
java term) short (as in K.I.S.S), this could become very readable AND
traceable. I'll have to look into that one further.

The last point I'd like to recap is concerning renaming. Some people
obviously consider this to be the worst thing to befall mankind and
about two years ago I would have agreed. Now, however, we've been using
rename for so long and so extensively that we actually have "renaming
conventions". Almost every file you open have a number of renames at the
top, renaming standard packages that we use extensively. These renames
are ALWAYS the same, which means that it actually becomes quite
readable. So why didn't we name the packages that way to start with, you
might ask. Simple. I know what TEPC is, but you don't. It really is a
package name of some 30 characters (yes, that long) which I don't want
to type and certainly don't want to read everytime it's used, but TEPC
is ok to read and it tells me what I need to know. If you don't know
what TEPC is, you just look it up in the rename section of the package.
This works, but I agree that it's not a perfect world...

So much for the recap. Thank you for all the comments, I'll ponder over
them as I look over our naming conventions and coding principles.

-Sven