Date: Thu, 30 Oct 1997 12:06:46 +0200 (IST)
From: Eli Zaretskii <eliz AT is DOT elta DOT co DOT il>
To: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
cc: djgpp-workers AT delorie DOT com, Randy Maas <randym AT acm DOT org>
Subject: Re: Style Sheet (was: Re: 971009: FileSysExt's Rev D. p2)
In-Reply-To: <34585139.930@rug.ac.be>
Message-ID: <Pine.SUN.3.91.971030115632.348O-100000@is>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Precedence: bulk


On Thu, 30 Oct 1997, Vik Heyndrickx wrote:

>     You are free to choose a commonly used indentation style, as long as
>     you are consistent.

DJ should decide, but I'd prefer a common indentation style.  Personally, 
I always stick to DJ's original style when editing librray sources, even 
though my own style is slightly different.

>     Choice 2:
>     if (expr) 
>     {
>       stat1;
>     } 
>     else 
>     {
>       stat2;
>     }

This is what DJ uses, as far as I could see.

>     Don't *ever* use tabs when distributing files. Expand them.

Why?  The current librray sources have plenty of TABs.

>   Rule 3: Positive types are unsigned, integer types are signed.

This can be dangerous.  In general, using a single type (signed or 
unsigned) is the best, since mixing them is a Bad Idea.  In practice, 
this means that you should use signed ints unless you MUST use unsigned 
ones.  If a quantity is always positive, there's no need IMHO to declare 
it unsigned.

> This is no style issue.

Then maybe it shouldn't be here.  (Will sertainly spare us another 
argument ;-).

>   Don't push it. 'current_file_position_in_4byte_counts' is no good for
>   reading AND typing.

I'm not sure I agree. If somebody doesn't mind typing them (and Emacs 
makes it very easy, once you have typed it once), why should you object?

>   Your module should compile without any warning if you compile with
>   -Wall.

-Wall is not enough.  There's a list of compilation switches used in 
compiling the library (I think in src/libc/gcc.opt or something) which 
should be used to see if it will compile.

>   Use file names that are the same on LFN & SFN systems. 
>   Stick to 8+3 and lower case.

What about .S files?  Can you have the same effect with a lower case 
extension?  If not, this rule is no good.

> What categories did I forget? 

What about avoiding to pollute ANSI/POSIX namespaces?