home *** CD-ROM | disk | FTP | other *** search
/ Big Green CD 8 / BGCD_8_Dev.iso / NEXTSTEP / UNIX / Shells / zsh-3.0.5-MIHS / src / Util / zsh-development-guide < prev   
Encoding:
Text File  |  1996-10-10  |  2.9 KB  |  74 lines
  1. # $Id: zsh-development-guide,v 2.2 1996/10/02 23:47:18 hzoli Exp $
  2. #
  3. # Guidelines for Zsh Development Group
  4. #
  5.  
  6. Zsh is currently developed and maintained by the Zsh Development Group.
  7. This development takes place by mailing list.  Check the META-FAQ for the
  8. various zsh mailing lists and how to subscribe to them.  The development
  9. is very open and anyone is welcomed and encouraged to join and contribute.
  10. Because zsh is a very large package whose development can sometimes
  11. be very rapid, I kindly ask that people observe a few guidelines when
  12. contributing patches and feedback to the mailing list.  These guidelines
  13. are very simple and hopefully should make for a more orderly development
  14. of zsh.
  15.  
  16. 1) Send all patches to the mailing list rather than directly to me.
  17.  
  18. 2) Send only context diffs "diff -c oldfile newfile".  They are much
  19.    easier to read and understand while also allowing the patch program
  20.    to patch more intelligently.
  21.  
  22. 3) Please put only one bug fix or feature enhancement in a single patch
  23.    and only one patch per mail message.  This helps me to multiplex
  24.    the many (possibly conflicting) patches that I receive for zsh.
  25.    You shouldn't needlessly split patches, but send them in the smallest
  26.    LOGICAL unit.
  27.  
  28. 4) If a patch depends on other patches, then please say so.  Also please
  29.    mention what version of zsh this patch is for.
  30.  
  31. 5) Please test your patch and make sure it applies cleanly. It
  32.    takes considerably more time to manually merge a patch into the
  33.    baseline code.
  34.  
  35. 6) Please try not using lines longer than 79 characters.  The coding style
  36.    is Kernighan and Ritchie with 4 characters indentations.  This means
  37.    that the opening brace is the last character in the line of the
  38.    if/while/for/do statement and the closing brace has its own line:
  39.  
  40.        if (foo) {
  41.        do that
  42.        }
  43.  
  44.    Put only one command in a line (this also means that the body of an
  45.    if/while/for/do statement has its own line with 4 characters indentation
  46.    even if there are no braces).  Do not use space between the function
  47.    name and the opening parenthesis.  Use space after if/for/while.  Use
  48.    space after type casts.  Do not use (unsigned char) casts since some
  49.    compilers do not handle them properly.  Use the provided STOUC(X) macro
  50.    instead.
  51.  
  52.    If you use emacs 19.30 or newer you can put the following line to your
  53.    ~/.emacs file to make these formatting rules the default:
  54.  
  55.    (add-hook 'c-mode-common-hook (function (lambda () (c-set-style "BSD"))))
  56.  
  57.    A global function declaration must look like this:
  58.  
  59. /**/
  60. int
  61. foo(char *s, char **p)
  62. {
  63.     function body
  64. }
  65.  
  66.     There must be an empty line, a line with /**/, a line with the type of
  67.     the function and finally the name of the function with typed arguments.
  68.     These lines should not be indented.  This rule is a must because the
  69.     script generating function prototypes and the ansi2knr program depends
  70.     on this format.
  71.  
  72. ZoltÆn HidvØgi      (Coordinator, Zsh Development Group)
  73. hzoli@cs.elte.hu
  74.