Re: Quick question about Ada code formatting.

[Simon Wright <simon@pushface.org>]

Georg Bauhaus <bauhaus@futureapps.de> writes:

> But indentation using 2 or 4 or 3 spaces is a typographical
> issue. -gnaty without further qualification is rather unforgiving
> when it forces reformatting of reused source code that happens not
> to follow -gnaty's defaults. The same comment applies to space
> before '(' and after "-- ". I'd prefer a less intrusive default
> meaning of -gnaty.

=gnaty was introduced to support AdaCore's in-house rules. I see no
point in writing a massively complex stylistic guide, we need a tool
(preferably an already-available one), so we just adopted -gnaty for
new code. As I've said before, I have little time for the artistic
approach if it leads to so-called engineers refusing to do what
they're paid to.

On the other hand, for re-used code (eg a matrix package, and even at
one point AUnit) we switched off -gnaty; we had no intention of
altering it, and indeed we had reasonably strict rules not to do so
without showing that it was truly necessary (style _not_ coming under
that heading!)

> -gnaty could be improved, in my view, by separating layout
> issues from issues that potentially affect how a piece of
> code can be organized, and compiled.
>
> For example, on the one hand -gnaty marks
> test.ada:2:04: (style) subprogram body has no previous spec
>
> and on the other hand,
> test.ada:3:09: (style) space required

The first case you mention seems to be the only -gnaty rule that has
any semantic effect at all, all the others are indeed style.

We also compile with -gnatwaL which is reasonably strict. I think
there are a coule of warnings not switched on by -gnatwa -- yes, d
(implicit dereferencing) and h (hiding) for a start.


>>> There is a study (from Kent?, comparing MISRA C and other style
>>> guides) that demonstrates how useless and wasteful typographic
>>> sophistry is.
>> 
>> Hmm, can't find anything like that on Google, any more pointers?
>
> The latest version I could find is here,
> http://www.leshatton.org/Documents/MISRAC.pdf
>
> The wording seems to have softened since a version dated 2002/05/24.
> The paragraph below Table 2 in that version starts:
>
> "The clear message from these studies is that a category A dominated
> programming standard is a complete waste of everybody's time and money."
>
> (Category A means "inherently artistic", "subjectively or stylistically
> based" rules. Category B.1 has "folklore rules" (e.g., no goto, never!)
> and B.2 denotes rules for which there exist actual data from measuring
> failures when not following these rules.)

I found the paper quite confused. It says that -- without tool support
-- a standard for C gets transgressed about once every 10 lines,
regardless of whether it's mainly A-based (stylistic) or B-based
(semantic).

Clearly one needs compiler halp as much as possible. If it has a
switch to warn about possibly-uninitialised variables one would be
irresponsible not to use it. Ditto for style, surely?

I also saw no evidence in it about whether code that didn't transgress
stylistic rules had fewer semantic errors as well.


I remember the Rational Environment. You had no choice about how your
code was presented, because the internal representation didn't store
layout; all you saw after the code had been internalised (semanticised
was the word they used) was a view of it, prepared on the fly. One
pretty soon got out of the habit of trying to force the system to do
something else!