Re: Don't use the "use" clause

["Ed Falis" <falis@verizon.net>]

On Mon, 21 Nov 2005 19:15:55 -0500, Anonymous Coward <spam@spam.com> wrote:

> I would agree that you can't argue taste purely on the merits of
> personal preference, but as soon as you bring in the bu$iness case,
> the answer becomes clear.

Actually, is doesn't become as clear as you think.  My company uses use  
clauses, and find the approach to have merit.

> Egocentrics who can't see outside
> themselves cannot effectively argue from the perspective of analysing
> code written by others.

Is that ad hominem?

>
> The cost of having too much information is *cheaper* than the cost of
> having too little information, because the trained eye can very
> quickly ignore what is not interesting.  It's certainly not equally
> fast to find missing information.

If the information is easy to hand, this argument evaporates, and clutter  
does have a cost.


> I know first hand from a project that had an unenforced prohibition on
> use clauses, for which the company lost copious manhours due to
> undisciplined programmers abusing the use clause (when combined with
> crappy tools).  Superior tools would have reduced thoses losses
> substantially.  But then you would have to consider the cost of the
> better tools themselves.  With the hypothetically best tools, and
> assuming they are better than a mouse over cross reference which will
> also accommodate code reviews, you're only breaking even at best.

No, there's the losing the forest for the trees effect as well.  I've  
consulted with many, many Ada projects that use the "no use clause"  
prohibition and seen an awful lot of wasted time due to people getting  
lost in the course of maintaining their code base.  And I've also seen  
companies that allow use of the clause that operated well.  This is all  
anecdotal evidence.  Tools don't cost very much compared to lost  
productivity.  I've been doing Ada since 1981, and have seen plenty of  
stupid conventional wisdom.  IMO, of course.

Let me tell you about the 300 line subprogram that was presented to me.   
The customer couldn't understand why certain code was never executed.  The  
nesting levels of the statement list were pushing 7 or 8 levels deep.   
After looking at it for a bit, it became clear that the subprogram was  
written so that the code in question could not be executed.  I rewrote the  
subprogram in 40 lines.  The sheer dirtiness and complexity (ie noise) of  
the code was the problem, and the several people who reviewed it couldn't  
determine that the subprogram was doing exactly what it was told to.   
Noise overwhelmed their ability to analyze what was happening.  An extreme  
case, but not all that uncommon in code I've seen.

- Ed