Prev: Debugger for GNAT
Next: Help installing GCC/GNAT 4.0.2
From: Ed Falis on 21 Nov 2005 14:20
On Mon, 21 Nov 2005 12:36:47 -0500, David Emery <demery(a)cox.net> wrote:

> it's possible to construct programming environments that can show you
> the unambiguous source for each name/
> operator. But such information is transient, it only lasts for as long
> as you have the mouse/etc there. Often I'm sufficiently "Luddite" that
> I print out and scribble over hardcopies of programs.
>


I think this is a case of "your mileage may vary", or "you can't argue
taste". I've never missed fully qualified names (and dislike those cute
little package renamings to acronyms - which I really hate). The cost of
full qualification (particularly when the environment supports
cross-referencing) is cluttered code.

But we can all agree to disagree, provided we follow the coding
conventions of our employers ;-)

- Ed
From: David Trudgett on 21 Nov 2005 17:21
"Ed Falis" <falis(a)verizon.net> writes:

>
> But we can all agree to disagree, provided we follow the coding
> conventions of our employers ;-)

Can we agree to disagree even if we don't follow the coding
conventions of our employers? ;-)

David



--

David Trudgett
http://www.zeta.org.au/~wpower/

Beware of bugs in the above code;
I have only proved it correct, not tried it.

-- Donald Knuth (1977)

From: Ed Falis on 21 Nov 2005 17:51
On Mon, 21 Nov 2005 17:21:09 -0500, David Trudgett
<wpower(a)zeta.org.au.nospamplease> wrote:

> Can we agree to disagree even if we don't follow the coding
> conventions of our employers?

Works for me with my own code ;-)
From: Anonymous Coward on 21 Nov 2005 19:15
In article <op.s0lunzyd5afhvo(a)localhost>,
Ed Falis wrote:
>
> I think this is a case of "your mileage may vary", or "you can't
> argue taste".

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. Egocentrics who can't see outside
themselves cannot effectively argue from the perspective of analysing
code written by others.

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.

To test that claim, simply go to a web site with banner ads. Can you
find the interesting content quicker than you can mouse around and
click the Firefox "ad block" tab on the unwanted ad? Probably. I
don't even see the banner ads anymore.

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.
From: Ed Falis on 22 Nov 2005 23:09
On Mon, 21 Nov 2005 19:15:55 -0500, Anonymous Coward <spam(a)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
First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4
Prev: Debugger for GNAT
Next: Help installing GCC/GNAT 4.0.2