Re: [GNU-COBOL] standards & practices

["John J. Adelsberger III" <jja@umr.edu>]

I've snipped the parts that are obviously good ideas.  The rest is comments,
and not flames.  If you can't reply in kind, don't bother, because the
next personal attack I see will be the last chance you have of me giving
a damn about this project.

> 1) All code will be Readable and Maintainable.

You could put 10 software experts(as in, more experience than any of
us) in a room with those words, and you'd get at least 15 contradictory
opinions on what they mean.  They're a laudable goal, but since just
about everyone agrees on them, putting them in a standards document
serves no purpose whatsoever , but _does_ give you a blanket excuse to
reject code without having a real reason.

> 5) All C code will be Ansi & Posix compliant. except no using trigraphs.

Might want to require the ansi switches on gcc in this case...  otherwise,
you can get GNU specific extensions without knowing it.

> 7) As the issue was brought. I see no conflict between the GNU coding standard
>    and the first rule.

The GNU specs are usually more specific(return types go on a line preceding
the function, etc etc.)  But no, I don't see any conflicts per se, and
the GNU indentation style can be produced by indent if it matters.

> 7a) 18 - Code formatting beyond 80 columns and needs to be "folded" 
>    Rewrite the code so "folding" isn't necessary.

Granted, if you don't do it very neatly, line continuation is ugly, but
I can show you examples of code that _cannot_ be rewritten as you
suggest(usually function calls with lots of arguments.)  Also, rewriting
nested loops each of which executes only a few times but whose nesting
is important is usually a bad idea because the result will be a very
unnatural implementation of the idea behind it.  In short, if you're
doing anything more interesting than a simple linear chain of API
calls, you're probably hosed by this rule.

> 7b) 20 - All pointer declaration need to be on a line by them self.
>    Ex:  char * one, *two;   /* this is a no-no */
>         /* better way */
>         char *one;
>         char *two;

I'll do this, but it isn't a good idea.  Usually no big deal,
but on occasion, you use 5 or 6 pointers, or even more, and your way, 
they'll take up a good portion of a screenful of text for no noticable 
gain.

> 7c) 21 -  variable names.
>    It suggests the use of underscores as separators in C. BUT
>    Variable names should use mixed case, instead of underscores.

If that's what we're going with, I'll do it, but I have to ask: WHY?
This is MUCH harder on the eyes than underscores, and it makes any
abbreviation within an identifier utterly unreadable.  In addition,
it means that your code looks inconsistent when you make calls
to standard libraries and other peoples' code.  Inconsistency looks
bad and distracts your attention from the code, making it harder
to understand.  Far better to pick the way typically done in a given
language(which is what you suggest in Java, but isn't in C.)

-- 
John J. Adelsberger III
jja@umr.edu

"Civilization is the process of setting man free from men."

						- Ayn Rand

--
This message was sent through the gnu-cobol mailing list.  To remove yourself
from this mailing list, send a message to gnu-cobol@acm.cs.umr.edu with the
words "unsubscribe gnu-cobol" in the message body.  For more information on
the GNU COBOL project, send mail to gnu-cobol-owner@acm.cs.umr.edu.