Re: ada writing guide

[tmoran@bix.com]

> http://www.delorie.com/gnu/docs/GNU/standards_toc.html
>
> This provides a coding stabndard for C, which could be considered "strict."

It's hard to know what to say.  A document dated 1999 that gives a
standard for C and cautions against using any other language, including
C++.  A document whose "C style" part is all of 550 lines, or ten pages,
in length, whereas "Ada Quality and Style" manages somehow to take 270
pages.  A "strict" standard for the "C" language with statements like:

"Please use formfeed characters (control-L) to divide the program
into pages"

"Insert extra parentheses so that Emacs will indent the code properly."

"We find it easier to read a program when it has spaces before the
operator, not after one. Here is the right way:"

"Please put two spaces after the end of a sentence in your comments,
so that the Emacs sentence commands will work."

"Please write the comments in a GNU program in English,
because English is the one language that nearly all
programmers in all countries can read."

I guess the adjective "strict" does apply in cases like:

"It is important to put the open-brace that starts the
body of a C function in column zero, and avoid putting
any other open-brace or open-parenthesis or open-bracket
in column zero. Several tools look for open-braces in
column zero to find the beginnings of C functions. These
tools will not work on code not formatted that way.

It is also important for function definitions to start the name of the
function in column zero. This helps people to search for function
definitions, and may also help certain tools recognize them."

I prefer Ada, and even if I was coding in GNU C, I'd read Ada Quality
and Style for ideas.