Sender: vheyndri AT rug DOT ac DOT be
Message-Id: <34585139.930@rug.ac.be>
Date: Thu, 30 Oct 1997 10:19:53 +0100
From: Vik Heyndrickx <Vik DOT Heyndrickx AT rug DOT ac DOT be>
Mime-Version: 1.0
To: djgpp-workers AT delorie DOT com
Cc: Randy Maas <randym AT acm DOT org>
Subject: Style Sheet (was: Re: 971009: FileSysExt's Rev D. p2)
References: <3 DOT 0 DOT 1 DOT 32 DOT 19971015163553 DOT 0069d4d4 AT yacker DOT xiotech DOT com> <3 DOT 0 DOT 1 DOT 32 DOT 19971029125703 DOT 007ca690 AT yacker DOT xiotech DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Precedence: bulk

Randy Maas wrote:
> 3.  Coding style.  I could not find a style sheet.  

Good question. AFAIK there is none.
Maybe a good time to start one.
Here is what I suggest. Please send all flames & suggestions to me.

- Indentation
  For all new program files:
    You are free to choose a commonly used indentation style, as long as
    you are consistent.
    Choice 1:
    if (expr) {
      stat1;
    } else {
      stat2;
    }

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

    Choice 3:
    if (expr)
      {
      stat1;
      }
    else
      {
      stat2;
      }
    
    Not-nested function definitions and declarations start at the most
    left hand position.
    Preprocessor directive lines start at the most left hand position.
    There is no whitespace after # before a preprocessor directive.
    Include only 1 header file in a single #include line.
    Put #include <...> lines before #include "..." lines.

    Don't *ever* use tabs when distributing files. Expand them.
    Virtual TAB steps should be 2.

- Variable types.
  In order of importance.
  Rule 0: Use your mind.
  Rule 1: Match ANSI & POSIX standards if appropriate.
          Don't hesitate to use types like size_t, ptrdiff_t, ...
  Rule 2: Be consistent. If you assign from a function returning int 
          your variable will usually also be int, unless there is a 
          good reason to do otherwise (rule 0).
  Rule 3: Positive types are unsigned, integer types are signed. This is
          no style issue. Be aware of subtle bugs you may create if you
          choose wrong.
          Use the shortest names for types.
            'int' instead of 'signed int' or 'signed'
            'unsigned' instead of 'unsigned int'
            'long unsigned' instead of 'long unsigned int'
          Put 'short'/'long'/'long long' always before 'unsigned', 
          'int'.
          Be *very* careful with 'char'. Try always to use 'unsigned 
          char' or 'singed char', except when used in prototypes.
  Rule 4: For types that match explicitely i386 processor features (like
          offsets and selectors), use explicitely long or short
          instead of plain int or unsigned int.
  Rule 5: 'const' is an ANSI feature. Use it in pointers, if the values
          where they point to, should remain unchanged.
  Rule 6: GNU C doesn't like 'char' and 'short'. Don't use them, unless
          you really want to limit the variable's range (like selectors, 
          but that's Rule 4). If you use them extensively, your program
          module may become bigger and run more slowly.

- Variable names:
  Don't use generic names for global symbols. Give them meaningful
  non-context depend names. 
  Except for dummy counter values like i, j use meaningful names for
  local symbols. Don't abbreviate too much, like 'position' to 'p', 
  but 'pos' should be fine.
  Don't push it. 'current_file_position_in_4byte_counts' is no good for
  reading AND typing.
  Don't reuse local variables. 
  
- Compilation:
  Your module should compile without any warning if you compile with
  -Wall.

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

What categories did I forget? 

-- 
 \ Vik /-_-_-_-_-_-_/   
  \___/ Heyndrickx /          
   \ /-_-_-_-_-_-_/