Re: Don't use the "use" clause

[Stephen Leake <stephen_leake@acm.org>]

"Jeffrey R. Carter" <spam@spam.com> writes:

>>>I agree.  I personally take it an extreme step further, and never use
>>>use clauses anywhere.  They shouldn't even be in the language.  Every
>>>Ada project I've worked on that had a coding standard banned the use
>>>clause, and rightly so.

Hmph. _My_ coding standard doesn't say that.

It says "no use clauses in package specs. Use clauses in bodies must
be localized as much as possible, and should be used whenever the
package name is present in several statements within a declarative
region". 

That preserves very clear references in package specs, where they are
most important, preserves fairly clear references in package bodies,
and improves readability of subprograms. As it should be :).

>> Three features of the language, all useful at times, are the
>> visibility clause (use) and the renames option, and the goto. Even
>> though all are potentially problematic, they are also useful at
>> times.
>
> Right. The OP might want to use SPARK, which does not have use clauses.

That seems odd. What does SPARK gain by outlawing use clauses? Surely
the examiner can handle the extra name resolution!

>> Visibility is one of the most least understood concepts in Ada. It
>> drives new Ada programmers nuts. 

That has not been my experience. Perhaps my coding standard is enough
to prevent that, or perhaps the GNAT error messages are good enough.

>> Experience Ada programmers learn to appreciate its power and find
>> it useful. 

yes.

>> The also know when visibility clauses are appropriate and when they
>> are not. This is not, as someone else mentioned, simply a matter of
>> taste. It is not just a matter of style.
>
> There's also a question of judgment. The packages in the core language
> definition and the standard library (Ada.*) should be familiar to
> anyone reading Ada code; using these packages should not impact
> readability. A project may have a its own standard library in addition
> to these, that should be familiar to anyone working on the project,
> and a similar argument applies to these. A package used in a single
> subsystem of a large project is a different creature and is probably
> not a good candidate for use.

It's not a question of "familiarity". I'm totally familiar with the
code I wrote today, but next year I won't be. 

It's a question of balance between distance from the full package
name, and readability.

-- 
-- Stephe