1. 28 Apr, 2000 1 commit
  2. 27 Apr, 2000 1 commit
    • David Lawrence's avatar
      Vertical whitespace is encouraged for improved code legibility by · e1747e09
      David Lawrence authored
      grouping closely related statements and then separating them with a
      single empty line.
      Lines should not be longer than 79 characters, even if it requires
      violating the indentation rules to do so.  Since ANSI is assumed, the
      best way to deal with strings that extend past column 79 is to break
      them into two or more sections separated from each other by a newline
      and indentation. (w/example)
      Note that <isc/lang.h> should be included by any public
      header file to get the ISC_LANG_BEGINDECLS and ISC_LANG_ENDDECLS
      macros used so the correct name-mangling happens for function
      declarations when C++ programs include the file. <isc/lang.h> should
      be included for private header files or for public files that do not
      declare any functions. (w/example)
      Fixed < and > use in sample header file.
      The config.h file must never be included by any public header file.
      The comma operator should not be used to form compound statements.
      Generally speaking, when a control statement (<CODE>if, for</CODE> or
      <CODE>while</CODE>) has only a single action associated with it, then no
      bracing is used around the statement.  Exceptions include when the
      compiler would complain about an ambiguous else clause, or when extra
      bracing improves the readability (a judgement call biased toward not
      having the braces).
      Do not put a space after the "sizeof" operator name, and also
      parenthesize its argument, as in <CODE>malloc(4 * sizeof(long))</CODE>.
      Do not put a space after a cast. (w/example)
      <H4>The Ternary Operator</H4> (w/example)
      The ?: operator should mostly be avoided.  It is tolerated when
      deciding what value to pass as a parameter to a function, such as
      frequently happens with printf, and also when a simple (non-compound)
      value is being used in assignment or as part of a calculation.
      In particular, using the ternary operator to specify a return value is
      verboten. (Well, Bob didn't tell me *forbidden* when he first said this
      to me long ago, but I got the impression he really did not like it.)
      Variables should not have their values assigned or changed when being
      passed as parameters, except perhaps for the increment and decrement
      operators. (This came up when I found something much like this in one
      of our files:
             malloc(size = 20);
      All public interfaces to functions, macros, typedefs, and
      variables provided by the library, should use names of the form
      {library}_{module}_{what}, such as:
             isc_buffer_t                            /* typedef */
             dns_name_setbuffer(name, buffer)       /* function */
             ISC_LIST_HEAD(list)                    /* macro */
             isc_commandline_argument               /* variable */
      however, structures which are typedef'd generally have the name of the
      typedef sans the final _t:
             struct dns_rbtnode {
                     /* ... members ... */
      Generally speaking macros are defined with all capital letters, but
      this is not universally consistent (eg, numerous isc_buffer_{foo}
      The {module} and {what} segments of the name do not have underscores
      separating natural word elements, as demonstrated in
      isc_commandline_argument and dns_name_setbuffer above.  The {module}
      part is usually the same as the basename of the source file, but
      sometimes other {module} interfaces appear within one file, such as
      dns_label_* interfaces in lib/dns/name.c.  However, in the public
      libraries the file name must be the same as some module interface
      provided by the file; e.g., dns_rbt_* interfaces would not be declared
      in a file named redblack.c (in lieu of any other dns_redblack_*
      interfaces in the file).
      The one notable exception to this naming rule is the interfaces
      provided by <isc/util.h>.  There's a large caveat associated with the
      public description of this file that it is hazardous to use because it
      pollutes the general namespace.
      <H4>Shared Private Interfaces</H4>
      When a module provides an interface for internal use by other modules
      in the library, it should use the same naming convention
      described for the public interfaces, except {library} and {module}
      are separated by a double-underscore.  This indicates that the name is
      internal, its API is not as formal as the public API, and thus it
      might change without any sort of notice.
  3. 02 Nov, 1999 1 commit
  4. 22 Apr, 1999 1 commit
  5. 09 Feb, 1999 1 commit