Re: Quick question about Ada code formatting.

[Georg Bauhaus <bauhaus@futureapps.de>]

Simon Wright wrote:

>>  - Consistent use of whatever non-typographical convention
>>    is in use.
> 
> Yes, precisely. That is *exactly* the point!

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 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

These messages point to different issues, the first says something
about a program's organization. It refers to the fundamental
issue of separating spec and implementation. The second is largely
a typographic issue. It has no relevance for program organization.


>> An additional proof of -gnaty being overly strict is when it comes
>> function names in GUI programming.  Many do not want to see '_'s in
>> identifiers when they are use to them without the underscores. Note
>> the "used to"... :-)
> 
> I don't understand that. I have GLIDE and GPS set up to recognise the
> correct casing of lots of words: my ~/.emacs_case_exceptions is

I was confused. There are style rules that say that Ada style identifiers
with '_' are always prefereble, so please rewrite the system call names.
CreateWindow then becomes Create_Window, and not Windows.Create, say.
The latter leaves no doubt that there is a layer of abstraction.

(Side note: The SmartEiffel team has decided to modify their Eiffel
language such that typical Eiffel style rules become syntax rules.
No exceptions.
This entails case restrictions, referred to as "case sensitivity".
So no more "Henry_III" constant identifiers in SmartEiffel programs,
only "Henry_iii". One version of the compiler in fact forced you
to write "henry_iii". And SmartEiffel, the official name, is written
"smart_eiffel" in the source files.)

>> 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.)