comp.lang.ada
 help / color / mirror / Atom feed
* Re: explicit null
@ 1996-05-09  0:00 W. Wesley Groleau (Wes)
  1996-05-09  0:00 ` Robert A Duff
  0 siblings, 1 reply; 3+ messages in thread
From: W. Wesley Groleau (Wes) @ 1996-05-09  0:00 UTC (permalink / raw)



:> Subject: Re: To Initialise or not
:> So, here's my summary [of his opinions on explicitly initializing to null]:

With what will REALLY happen, IMHO.

:> 1. The convention is not self-evident. It has to be explained somewhere. If
 the
:> maintainer fails to get that understanding, it will cause confusion while
 (s)he
:> searches for the meaning to this "useless" code.

The chances of the above search occurring under deadline pressure are
'null' :-)  With no pressure, about 5%.  If what I've observed in twenty
years of working with other people is typical, more than half will not
notice the explicit null.  Of those that do notice it, most will think,
"Whoever wrote this doesn't know Ada very well."  They will remove the
"unnecessary construction" and maybe even search the file for other
"unnecessary constructions."  Having the mindset to find such, they will
fmisjudge things that ARE necessary and remove them too.  (Yes, I've done
it myself, and I'm not alone.)  Then, if they are fortunate to work where
there are peer reviews, they will go to a review where everyone will say,
"I didn't find anything wrong with it."  (And the honest ones will add,
"Of course, I only looked at it for five minutes.")

:> 2. Even if the convention is understood, its value is hampered by the fact
 that
:> it doesn't convey information at the point where it is needed (the algorithm
:> using the data structure).
:>
:> 3. As a corollary to #2, further maintenance of the code makes it easy for
 the
:> coding convention to be inconsistently applied. This further obfuscates the
:> code.

This effect magnified by the one I've already described.

:> 4. Because it is "active" code which the compiler analyzes (unlike a
 comment),
:> there is also the danger (admittedly slight) of a coding error being
:> introduced.

This effect magnified by the one I've already described.

:> Overall, I stand by my original statement: I don't see the attraction of this
:> style.

Me, neither.  One exception: I have run across a compiler that failed to
initialize access fields in certain nested record situations.  But then
I would take half a line AT EACH SUCH LOCATION to explain why there's
an explicit null.

--
---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Magnavox - Mail Stop 10-40                               Home: 219-471-7206
Fort Wayne,  IN   46808              elm (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: explicit null
  1996-05-09  0:00 explicit null W. Wesley Groleau (Wes)
@ 1996-05-09  0:00 ` Robert A Duff
  1996-05-10  0:00   ` Ken Garlington
  0 siblings, 1 reply; 3+ messages in thread
From: Robert A Duff @ 1996-05-09  0:00 UTC (permalink / raw)



In article <9605091727.AA01200@most>,
W. Wesley Groleau (Wes) <wwgrol@PSESERV3.FW.HAC.COM> wrote:
>The chances of the above search occurring under deadline pressure are
>'null' :-)  With no pressure, about 5%. ...

You're correct, of course.  In most projects, in most situations.
But it seems to me that this is an argument against having *any* coding
conventions beyond what the language RM actually requires.

>...  If what I've observed in twenty
>years of working with other people is typical, more than half will not
>notice the explicit null.  Of those that do notice it, most will think,
>"Whoever wrote this doesn't know Ada very well."  They will remove the
>"unnecessary construction" and maybe even search the file for other
>"unnecessary constructions."  Having the mindset to find such, they will
>fmisjudge things that ARE necessary and remove them too.

True, if people don't understand the convention, they won't obey, and
they'll change code to disobey it.  But this seems like a point against
*any* sort of coding convention.

See, for example, the way ACT works, for a situation in which people
actually pay attention to project-wide conventions.

>Me, neither.  One exception: I have run across a compiler that failed to
>initialize access fields in certain nested record situations.  But then
>I would take half a line AT EACH SUCH LOCATION to explain why there's
>an explicit null.

Indeed.  Every time I write code in a certain way just because some
compiler has a bug, you'll see a comment in the code to that effect.

- Bob




^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: explicit null
  1996-05-09  0:00 ` Robert A Duff
@ 1996-05-10  0:00   ` Ken Garlington
  0 siblings, 0 replies; 3+ messages in thread
From: Ken Garlington @ 1996-05-10  0:00 UTC (permalink / raw)



Robert A Duff wrote:
> 
> In article <9605091727.AA01200@most>,
> W. Wesley Groleau (Wes) <wwgrol@PSESERV3.FW.HAC.COM> wrote:
> >The chances of the above search occurring under deadline pressure are
> >'null' :-)  With no pressure, about 5%. ...
> 
> You're correct, of course.  In most projects, in most situations.
> But it seems to me that this is an argument against having *any* coding
> conventions beyond what the language RM actually requires.

Actually, I think it's more of an argument for having coding conventions
(related to communicating developer intent) that are

  a. Obvious as to the intent.

  b. As close as possible to the point where the information is needed.

  c. Not redundant with information that can reasonably be gleaned from
     code analysis tools.

Coding standards that don't meet this criteria generally, in my experience,
have two problems: (1) they tend to be used inconsistently/incorrectly by
the developer, and (2) they tend to "drift" further off as the code is
maintained. They usually end up causing more problems then they solve.


-- 
LMTAS - "Our Brand Means Quality"




^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~1996-05-10  0:00 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1996-05-09  0:00 explicit null W. Wesley Groleau (Wes)
1996-05-09  0:00 ` Robert A Duff
1996-05-10  0:00   ` Ken Garlington

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox