cvs commit: apache-devsite styleguide.html

1998-04-20 Thread brian
brian   98/04/19 22:32:47

  Modified:.styleguide.html
  Log:
  Clarify that it's GNU indent.
  
  Revision  ChangesPath
  1.7   +1 -1  apache-devsite/styleguide.html
  
  Index: styleguide.html
  ===
  RCS file: /export/home/cvs/apache-devsite/styleguide.html,v
  retrieving revision 1.6
  retrieving revision 1.7
  diff -u -r1.6 -r1.7
  --- styleguide.html   1998/02/12 14:39:23 1.6
  +++ styleguide.html   1998/04/20 05:32:47 1.7
  @@ -21,7 +21,7 @@
   functions. The guidelines can be broken if necessary to acheive a
   clearer layout]
   
  -This style can be generated with the following arguments to indent:
  +This style can be generated with the following arguments to GNU indent:
   
   -i4 -npsl -di0 -br -nce -d0 -cli0 -npcs -nfc1
   
  
  
  


cvs commit: apache-devsite styleguide.html

1998-01-12 Thread pcs
pcs 98/01/12 06:18:07

  Modified:.styleguide.html
  Log:
  Update my email address. Hey, spam bots, new email address over here!
  
  Revision  ChangesPath
  1.5   +1 -1  apache-devsite/styleguide.html
  
  Index: styleguide.html
  ===
  RCS file: /export/home/cvs/apache-devsite/styleguide.html,v
  retrieving revision 1.4
  retrieving revision 1.5
  diff -u -r1.4 -r1.5
  --- styleguide.html   1997/08/01 20:08:49 1.4
  +++ styleguide.html   1998/01/12 14:18:06 1.5
  @@ -5,7 +5,7 @@
   Apache Developers' C Language Style Guide
   
   Compiled by Paul Sutton mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]. Based on a 
vote
  +HREF="mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]. Based on a 
vote
   taken in November, 1996.
   
   Further refinements voted upon in July 1997.
  
  
  


cvs commit: apache-devsite styleguide.html

1997-08-01 Thread Rodent of Unusual Size
coar97/08/01 13:08:51

  Modified:. styleguide.html
  Log:
Update style guide with the majority results from the most
recent issue vote.
  
  Revision  ChangesPath
  1.4   +100 -46   apache-devsite/styleguide.html
  
  Index: styleguide.html
  ===
  RCS file: /export/home/cvs/apache-devsite/styleguide.html,v
  retrieving revision 1.3
  retrieving revision 1.4
  diff -u -r1.3 -r1.4
  --- styleguide.html   1997/07/16 10:15:48 1.3
  +++ styleguide.html   1997/08/01 20:08:49 1.4
  @@ -4,9 +4,11 @@
   
   Apache Developers' C Language Style Guide
   
  -Compiled by Paul Sutton mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]. Based on a vote
  +Compiled by Paul Sutton mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]. Based on a 
vote
   taken in November, 1996.
  +
  +Further refinements voted upon in July 1997.
   
   
   
  @@ -24,42 +26,55 @@
   -i4 -npsl -di0 -br -nce -d0 -cli0 -npcs -nfc1
   
   The Guidelines
  +  
  +   Opening braces are given on the same lines as statements, or on the 
  +following line at the start of a function definition.
  +   
  +   Code inside a block (whether surrounded by braces or not) is
  +indented by four space characters. Tab characters are not
  +used. Comments are indented to the same level as the surrounding
  +code.
  +   
  +   Closing braces are always on a separate line from surrounding
  +code, and are indented to line up with the start of the text on
  +the line containing the corresponding opening brace.
  +   
  +   Functions are declared with ANSI-style arguments.
  +   
  +   There is no space between the function name and the opening bracket
  +of the arguments to the function. There is a single space following
  +commas in argument lists and the semi-colons in for statements.
  +   
  +   Inside a switch() statement, the case
  +keywords are indented to the same level as the switch line.
  +   
  +   Operators in expressions should be surrounded by a single space
  +before and after, except for unary increment (++), decrement (--), and
  +negation (!) operators.
  +   
  +   There is no whitespace between a cast and the item modified
  +(e.g., "(int)j" and not
  +"(int) j").
  +   
  +   If a cast is to a pointer type, there is a space between the type
  +and the * character (e.g.,
  +"(char *)i" instead of
  +"(char*)i")
  +   
  +  
   
  -Opening braces are given on the same lines as statements, or on the 
  -   following line at the start of a function definition.
  -
  -Code inside a block (whether surrounded by braces or not) is
  -   indented by four space characters. Tab characters are not
  -   used. Comments are indented to the same level as the surrounding
  -   code.
  -
  -Closing braces are always on a separate line from surrounding
  -   code, and are indented to line up with the start of the text on
  -   the line containing the corresponding opening brace.
  -
  -Functions are declared with ANSI-style arguments.
  -
  -Inside a switch() statement, the "case" keywords are indented to
  -   the same level as the "switch" line.
  -
  -There is no space between the function name and the opening bracket
  -   of the arguments to the function. There is a single space following
  -   commas in argument lists and the semi-colons in for statements.
  -
  -Operators in expressions should be surrounded by a single space
  -   before and after, except for increment and decrement operators.  
   
   Details and Examples
   
   
  -Indentation, General Style
  +Indentation, General Style
   
   Each level of indentation of code is four spaces. Tab characters
  should never be used. Specific indentation rules for function
  declarations and control-flow keywords are given below.
   
   Example:
  -
  +
   main(int argc, char **argc)
   {
   if (argc != 0) {
  @@ -68,8 +83,31 @@
   }
   exit(0);
   }
  -
  -Comments
  +
  +
  +If an expression (or a routine declaration or
  +invocation) would extend 
  +past column 80, the terms or arguments are wrapped at a convenient spot
  +and the wrapped portion is indented under the first term in the expression
  +(or the first argument to the function).
  +Conditional expressions should be wrapped to keep single or
  +parenthesized terms as atomic as possible, and place Boolean operators
  +at either the start (preferable) or end of the line.
  +
  +
  +Example:
  +
  +
  + static const char *really_long_name(int i, int j,
  + const char *args, void *foo,
  + int k)
  +
  + if (cond1 && (item2 || item3) && (!item4)
  + && (item5 || item6) && item7) {
  + do_a_thing();
  + }
  +
  +Comments
   
   Provide comments which explain the function of code where it is not
  clear from the code itself.  Pro

cvs commit: apache-devsite styleguide.html

1997-07-16 Thread Paul Sutton
pcs 97/07/16 03:15:49

  Modified:. styleguide.html
  Log:
  Update indent options
  
  Revision  ChangesPath
  1.3   +1 -1  apache-devsite/styleguide.html
  
  Index: styleguide.html
  ===
  RCS file: /export/home/cvs/apache-devsite/styleguide.html,v
  retrieving revision 1.2
  retrieving revision 1.3
  diff -C3 -r1.2 -r1.3
  *** styleguide.html   1997/07/09 22:04:42 1.2
  --- styleguide.html   1997/07/16 10:15:48 1.3
  ***
  *** 21,27 

This style can be generated with the following arguments to indent:

  ! -npsl -di0 -br -nce -d0 -cli0 -npcs

The Guidelines

  --- 21,27 

This style can be generated with the following arguments to indent:

  ! -i4 -npsl -di0 -br -nce -d0 -cli0 -npcs -nfc1

The Guidelines

  
  
  


cvs commit: apache-devsite styleguide.html

1997-07-09 Thread Paul Sutton
pcs 97/07/09 15:04:44

  Modified:. styleguide.html
  Log:
  HTML fix, typo.
  
  Revision  ChangesPath
  1.2   +2 -2  apache-devsite/styleguide.html
  
  Index: styleguide.html
  ===
  RCS file: /export/home/cvs/apache-devsite/styleguide.html,v
  retrieving revision 1.1
  retrieving revision 1.2
  diff -C3 -r1.1 -r1.2
  *** styleguide.html   1997/06/17 10:43:34 1.1
  --- styleguide.html   1997/07/09 22:04:42 1.2
  ***
  *** 2,8 
Apache Developers' C Language Style Guide


  ! Apache Developers' C Language Style Guide

Compiled by Paul Sutton mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]. Based on a vote
  --- 2,8 
Apache Developers' C Language Style Guide


  ! Apache Developers' C Language Style Guide

Compiled by Paul Sutton mailto:[EMAIL PROTECTED]">[EMAIL PROTECTED]. Based on a vote
  ***
  *** 12,18 

Introduction

  ! [This bit could state That code should be laid out to be clear to
someone else familiar with Apache. Functions should be short and
easily understood. Comments should be provided to explain the
rationale for code which is not obvious, and to document behavior of
  --- 12,18 

Introduction

  ! [This bit could state that code should be laid out to be clear to
someone else familiar with Apache. Functions should be short and
easily understood. Comments should be provided to explain the
rationale for code which is not obvious, and to document behavior of