0
+ − 1 XEMACS CODING STANDARDS
+ − 2
+ − 3 by
+ − 4
+ − 5 Ben Wing
+ − 6
+ − 7
+ − 8 Copyright (c) 1996 Ben Wing.
+ − 9
+ − 10
+ − 11 This file documents the coding standards used in the XEmacs source
+ − 12 code. Note that XEmacs follows the GNU coding standards, which are
+ − 13 documented separately in ../man/standards.texi. This file only
+ − 14 documents standards that are not included in that document; typically
+ − 15 this consists of standards that are specifically relevant to the
+ − 16 XEmacs code itself.
+ − 17
+ − 18 First, a recap of the GNU standards:
+ − 19
+ − 20 -- Put a space after every comma.
+ − 21 -- Put a space before the parenthesis that begins a function call,
+ − 22 macro call, function declaration or definition, or control
+ − 23 statement (if, while, switch, for). (DO NOT do this for macro
+ − 24 definitions; this is invalid preprocessor syntax.)
+ − 25 -- The brace that begins a control statement (if, while, for, switch,
+ − 26 do) or a function definition should go on a line by itself.
+ − 27 -- In function definitions, put the return type and all other
+ − 28 qualifiers on a line before the function name. Thus, the function
+ − 29 name is always at the beginning of a line.
+ − 30 -- Indentation level is two spaces. (However, the first and following
+ − 31 statements of a while/for/if/etc. block are indented four spaces
+ − 32 from the while/for/if keyword. The opening and closing braces are
+ − 33 indented two spaces.)
+ − 34 -- Variable and function names should be all lowercase, with underscores
+ − 35 separating words, except for a prefixing tag, which may be in
+ − 36 uppercase. Do not use the mixed-case convention (e.g.
+ − 37 SetVariableToValue ()) and *especially* do not use Microsoft
+ − 38 Hungarian notation (char **rgszRedundantTag).
+ − 39 -- preprocessor and enum constants should be all uppercase, and should
+ − 40 be prefixed with a tag that groups related constants together.
+ − 41
+ − 42
+ − 43 Now, the XEmacs coding standards:
+ − 44
+ − 45 **** Specially-prefixed functions/variables:
+ − 46
+ − 47 -- All global C variables whose value is constant and is a symbol begin
+ − 48 with a capital Q, e.g. Qkey_press_event. (The type will always be
+ − 49 Lisp_Object.)
+ − 50 -- All other global C variables whose value is a Lisp_Object (this
+ − 51 includes variables that forward into Lisp variables plus others like
+ − 52 Vselected_console) begin with a capital V.
+ − 53 -- No C variables whose value is other than a Lisp_Object should begin
+ − 54 with a capital V. (This includes C variables that forward into
+ − 55 integer or boolean Lisp variables.)
+ − 56 -- All global C variables whose value is a struct Lisp_Subr begin with a
+ − 57 capital S. (This only occurs in connection with DEFUN ()).
+ − 58 -- All C functions that are Lisp primitives begin with a capital F,
+ − 59 and no others should begin this way.
+ − 60
+ − 61 **** Functions for manipulating Lisp types:
+ − 62
+ − 63 -- Any function that creates an empty or mostly empty Lisp object
+ − 64 should begin allocate_(). (*Not* make_().) (Except, of course,
+ − 65 for Lisp primitives, which usually begin Fmake_()).
+ − 66 -- Any function that converts a pointer into an equivalent Lisp_Object
+ − 67 should begin make_().
+ − 68 -- Any function that converts a Lisp_Object into its equivalent pointer
+ − 69 and checks the type and validity of the object (e.g. making sure
+ − 70 it's not dead) should begin decode_().
+ − 71 -- Any function that looks up a Lisp object (e.g. buffer, face) given
+ − 72 a symbol or string should begin get_(). (Except, of course, for
+ − 73 Lisp primitives, which usually begin Fget_()).
+ − 74
+ − 75 **** Other:
+ − 76
+ − 77 -- Any header-file declarations of the sort
+ − 78
+ − 79 struct foobar;
+ − 80
+ − 81 go into the "types" section of lisp.h.
