Re: Quick question about Ada code formatting.

Georg Bauhaus <bauhaus@xxxxxxxxxxxxx> 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!
.

Relevant Pages