From: Simon Wright <simon@pushface.org>
Subject: Re: Quick question about Ada code formatting.
Date: Sun, 19 Feb 2006 22:23:44 +0000
Date: 2006-02-19T22:23:44+00:00 [thread overview]
Message-ID: <m24q2vdm33.fsf@grendel.local> (raw)
In-Reply-To: 43f87015$0$13609$9b4e6d93@newsread2.arcor-online.net
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!
next prev parent reply other threads:[~2006-02-19 22:23 UTC|newest]
Thread overview: 58+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-18 12:19 Quick question about Ada code formatting Peter C. Chapin
2006-02-18 13:00 ` Ludovic Brenta
2006-02-18 13:26 ` Simon Wright
2006-02-18 15:36 ` Georg Bauhaus
2006-02-18 16:52 ` Georg Bauhaus
2006-02-19 0:27 ` Simon Wright
2006-02-19 4:17 ` Jeffrey R. Carter
2006-02-19 9:51 ` Simon Wright
2006-02-19 15:23 ` Stephen Leake
2006-02-19 22:32 ` Simon Wright
2006-02-19 12:23 ` Georg Bauhaus
2006-02-19 22:23 ` Simon Wright [this message]
2006-02-22 22:15 ` Stephen Leake
2006-02-22 23:13 ` Georg Bauhaus
2006-02-23 12:50 ` Stephen Leake
2006-02-23 15:40 ` Jean-Pierre Rosen
2006-02-18 19:16 ` Pascal Obry
2006-02-18 21:16 ` Peter C. Chapin
2006-02-18 21:27 ` Pascal Obry
2006-02-19 0:10 ` Simon Wright
2006-02-19 9:41 ` Pascal Obry
2006-02-19 9:57 ` Simon Wright
2006-02-19 10:29 ` Pascal Obry
2006-02-19 12:31 ` Georg Bauhaus
2006-02-19 13:29 ` Pascal Obry
2006-02-19 15:20 ` Stephen Leake
2006-02-20 6:33 ` Brian May
2006-02-20 18:07 ` Pascal Obry
2006-02-22 22:21 ` Stephen Leake
2006-02-20 8:17 ` Lionel Draghi
2006-02-20 19:07 ` Martin Krischik
2006-02-22 22:30 ` Stephen Leake
2006-02-22 22:39 ` Pascal Obry
2006-02-23 12:56 ` Stephen Leake
2006-02-23 15:02 ` Martin Krischik
2006-02-24 10:13 ` Stephen Leake
2006-02-24 19:02 ` Martin Krischik
2006-02-24 23:29 ` Georg Bauhaus
2006-02-20 18:52 ` Pascal Obry
2006-02-21 8:07 ` Alex R. Mosteo
2006-02-22 22:32 ` Stephen Leake
2006-02-23 6:02 ` Jeffrey R. Carter
2006-02-23 12:58 ` Stephen Leake
2006-02-19 19:25 ` Jeffrey R. Carter
2006-02-19 20:00 ` Pascal Obry
2006-02-19 22:27 ` Simon Wright
2006-02-20 4:32 ` Jeffrey R. Carter
2006-02-20 22:10 ` Randy Brukardt
2006-02-22 22:36 ` Stephen Leake
2006-02-23 9:49 ` Alex R. Mosteo
2006-02-23 12:42 ` Jean-Pierre Rosen
2006-02-24 10:15 ` Stephen Leake
2006-02-20 7:11 ` Jean-Pierre Rosen
2006-02-21 21:23 ` Simon Wright
2006-02-19 15:17 ` Stephen Leake
2006-02-18 14:43 ` Martin Krischik
2006-02-18 20:21 ` Jeffrey R. Carter
2006-02-19 10:02 ` Dmitry A. Kazakov
replies disabled
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox