IPP Software Navigation Tools IPP Links Communication Pan-STARRS Links

Changeset 501


Ignore:
Timestamp:
Apr 22, 2004, 10:30:32 AM (22 years ago)
Author:
eugene
Message:

some updates

File:
1 edited

Legend:

Unmodified
Added
Removed
  • trunk/doc/misc/codeConventions.tex

    r391 r501  
    1 %%% $Id: codeConventions.tex,v 1.12 2004-04-07 03:26:07 eugene Exp $
     1%%% $Id: codeConventions.tex,v 1.13 2004-04-22 20:30:32 eugene Exp $
    22\documentclass[panstarrs]{panstarrs}
    33
     
    7878(\code{http://java.sun.com/docs/codeconv/}) for more details.
    7979
    80 Such an adaption is is explicitly permitted by the Sun Microsystems
     80Such an adaption is explicitly permitted by the Sun Microsystems
    8181copyright notice (Copyright.doc.html).
    8282
     
    103103header files & \code{.h} \\
    104104SWIG interface files & \code{.i} \\
     105Perl files & \code{.pl} \\
     106Python files & \code{.py} \\
    105107\end{tabular}
    106108\end{center}
     
    141143\subsubsection{Include Files}
    142144
    143 Header files should have names starting \code{ps} or
    144 \code{p_ps} for private interface definitions. The latter
    145 should appear in a subdirectory \code{Private} of whichever
    146 directory is being searched for the public header files.
    147 
    148145Include files should have the following order:
    149146\begin{itemize}
     147\item
     148A brief description of the functionality provided by this set of APIs.
     149This comment should not duplicate information available
     150elsewhere (e.g. the filename; log information available from cvs).
     151
    150152\item
    151153A check for the existance of a CPP symbol of the form
     
    154156
    155157\item
    156 A brief description of the functionality provided by this set of APIs.
    157 This comment should not duplicate information available
    158 elsewhere (e.g. the filename; log information available from cvs).
     158Any \code{#define}d constants. {\bf Note:} \code{#define} should be used rather
     159than e.g. \code{const int}; C and C++ const semantics are different.
    159160
    160161\item
    161 Any \code{#define}d constants. N.b. \code{#define} should be used rather
    162 than e.g. \code{const int}; C and C++ const semantics are different.
     162Any enums.
    163163
    164164\item
    165 Any typedefs.
     165Any typedefs and structs.
    166166
    167167\item
     
    171171e.g. for file \file{psThing.h}:
    172172\begin{verbatim}
    173 #if !defined(PS_THING_H)
    174 #define PS_THING_H
    175173/*
    176174 * Support for psThings
    177175 */
    178 #define PS_NMAX 10                      /* maximum number of subthings */
    179 
     176
     177#if !defined(PS_THING_H)
     178#define PS_THING_H
     179
     180#define PS_NMAX 10                        // maximum number of subthings
     181
     182enum {PS_FIRST, PS_SECOND, PS_THRID};     // subthing sequences
    180183typedef struct {
    181     int nthing;                           /* number of subthings */
    182     int sthing[PS_NMAX];                  /* the subthings */
     184    int nthing;                           // number of subthings
     185    int sthing[PS_NMAX];                  // the subthings
    183186} psThing;
    184187
     
    188191#endif
    189192\end{verbatim}
     193\tbd{add doxygen comments to this example}
    190194
    191195\subsubsection{C Source Files}
     
    220224\section{Indentation}
    221225
    222 Four spaces should be used as the unit of indentation. The exact
    223 construction of the indentation (spaces vs. tabs) is unspecified. Tabs
    224 must be set exactly every 8 spaces (not 4).
     226Four spaces should be used as the unit of indentation.  Spaces are
     227recommended over tabs for indentation, but if tabs are used, the tabs
     228stops must be set to 8 spaces, not 4.
    225229
    226230\subsection{Line Length}
    227231
    228 Avoid lines longer than 110 characters, since they're not handled well by many terminals and tools.
     232Avoid lines longer than 110 characters.
    229233
    230234When preparing documents, you should ensure that lines of this length
    231 are not wrapped (If you are using the standard PSDC \LaTeX{} class
    232 file \file{panstarrs.cls}, \CODE|\begin{verbatim} ... \end{verbatim}|
    233 will do this for you).
     235are not wrapped\footnote{If you are using the standard PSDC \LaTeX{}
     236class file \file{panstarrs.cls}, \CODE|\begin{verbatim}
     237... \end{verbatim}| will do this for you}.
    234238
    235239\subsection{Wrapping Lines}
     
    252256
    253257\item Align the new line with the beginning of the expression at the
    254 same level on the previous line (for emacs users, this means the
    255 indentation that \code{<tab>} produces. If this isn't helpful to
    256 the majority of the people writing code for \PS{}, we can
    257 be more formal about what this rule means).
     258same level on the previous line\footnote{For emacs users, this means
     259the indentation that \code{<tab>} produces}.
    258260
    259261\item If the above rules lead to confusing code or to code that's
    260 squished up against the right margin, just indent 8 spaces instead.
    261 This should be \emph{very} rare! Consider whether you should be
    262 e.g. factoring code into a function.
     262squished up against the right margin, just indent 8 spaces
     263instead.\footnote{This should be \emph{very} rare! Consider whether
     264you should be e.g. factoring code into a function.}
     265
    263266\end{itemize}
    264267
     
    300303}
    301304
    302 //INDENT 4 SPACES TO AVOID VERY DEEP INDENTS
     305//INDENT 8 SPACES TO AVOID VERY DEEP INDENTS
    303306static type honkingLongFunctionName(
    304     int anArg,
    305     Object anotherArg, String yetAnotherArg,
    306     Object andStillAnother)
     307        int anArg,
     308        Object anotherArg, String yetAnotherArg,
     309        Object andStillAnother)
    307310{
    308311    ...
     
    400403
    401404\subsubsection{Trailing Comments}
     405\label{col40}
    402406
    403407Very short comments can appear on the same line as the code they
    404 describe, and should be indented to column 40 (in emacs, this
    405 may be achieved with \code{ESC;}). If the code extends beyond
    406 this column, the comment should be separated from the closing semi-colon
    407 by a single space.
     408describe, and should be indented to column 40\footnote{In emacs, this
     409may be achieved with \code{ESC;}}. If the code extends beyond this
     410column, the comment should be separated from the closing semi-colon by
     411a single space.
    408412
    409413Here's an example of a trailing comment in C code:
     
    479483\end{verbatim}
    480484
    481 (Note that the comments are indented to column 40).
     485(Note that the comments are indented to column 40, as per section~\ref{col40}).
    482486
    483487\subsection{Initialization}
     
    572576
    573577\begin{verbatim}
    574 void find_neos(const REGION *sky,       // bregion to search
    575                const char *descrip      // work orders
    576                )
     578void find_neos(const REGION *sky, const char *descrip)
    577579{
    578580    struct {
     
    717719\subsection{switch Statements}
    718720
    719 A \code{switch} statement should have the following form (note the
    720 indentation; the \code{case/default} is indented 2 spaces, the
    721 other statements are at the usual 4 space indent):
     721A \code{switch} statement should have the following form):
    722722\begin{verbatim}
    723723switch (condition) {
    724   case ABC:
    725     statements;
    726     /* falls through */
    727 
    728   case DEF:
    729   case GHI:
    730     statements;
    731     break;
    732 
    733   case XYZ:
    734     statements;
    735     break;
    736 
    737   default:
    738     statements;
    739     break;
     724    case ABC:
     725        statements;
     726        /* falls through */
     727
     728    case DEF:
     729    case GHI:
     730        statements;
     731        break;
     732
     733    case XYZ:
     734        statements;
     735        break;
     736
     737    default:
     738        statements;
     739        break;
    740740}
    741741\end{verbatim}
     
    756756added (not all compilers diagnose missing elements).  In this case,
    757757the action in the default clause should be to generate an error
    758 and abort.
     758\and abort.
     759
     760\subsection{label Statements}
     761
     762Code labels should be indented to align with the previous level of
     763indentation.
    759764
    760765%------------------------------------------------------------------------------
     
    799804
    800805\item
    801  Low priority binary operators (\code{+} and \code{-} and below)
    802 should be separated from their operands by spaces; higher
    803 precedence operators (e.g. \code{*}, \code{/}, \code{%},
    804   \code{.} and \code{->}) should not be separated by spaces.
    805 Blank spaces should never separate
    806 unary operators such as a type cast, unary minus, increment
    807 (\code{++}), and decrement (\code{--}) from their operands. Examples:
     806Binary operators should be separated from their operands by spaces.
     807Blank spaces should never separate unary operators such as a type
     808cast, unary minus, increment (\code{++}), and decrement (\code{--})
     809from their operands. Examples:
    808810\begin{verbatim}
    809811    a += c + d;
    810     a = (a + b)/(c*d);
     812    a = (a + b) / (c * d);
    811813   
    812814    while (*d++ = *s++) {                 // Tricky way of copying until '\0'
    813815        n++;
    814816    }
    815     printf("size is %d\n", foo);
     817    printf ("size is %d\n", foo);
    816818\end{verbatim}
    817819
     
    835837easier to read. They can also give information about the function of
    836838the identifier -- for example, whether it's a constant, a function, or
    837 a type -- which can be helpful in understanding the code.
     839a type -- which can be helpful in understanding the code.  Remember
     840these are guidelines for improving readability; clarity should trump
     841rigid adherence to the guideline.
    838842 
    839843\begin{tabular}{lp{3in}p{3in}}
     
    845849
    846850Type names should be nouns, in mixed case with the first letter of
    847 each internal word capitalized.
     851each internal word capitalized.  Little words, such as 'for', 'to',
     852'at', etc, may be written in all lower-case or separated with
     853underscores if it makes the name clearer.
    848854
    849855If and only if the type is visible at global scope, the
     
    11591165\end{verbatim}
    11601166
    1161 \textit{N.b. compilers are free to ignore the \code{restrict} keyword,
    1162 so all code should be written to explicitly handle aliasing}.
     1167\textit{{\bf Note:} compilers are free to ignore the \code{restrict}
     1168keyword, so all code should be written to explicitly handle aliasing}.
    11631169
    11641170\subsection{structs and typedefs}
     
    14381444\end{verbatim}
    14391445         
    1440 \bibliographystyle{plain}
     1446\section{How to Achieve This Style with Astyle}
     1447\label{astyle}
     1448
     1449The purpose of a coding standard is to improve coding efficiency, not
     1450to hinder it.  Since people are inherently falible, 100\% adherence to
     1451the standard is an impossible goal for human-generated code.
     1452Furthermore, laziness and slopiness are human nature.  To minimize the
     1453amount of effort spent in keeping software in line with a coding
     1454standard is to use automatic re-formatting tools to enforce the
     1455standard.  Various software tools exist to perform these tasks.  One
     1456of these is \code{astyle}, an open-source tool which takes a variety
     1457of options which allow the use to tailor the coding standard to suit
     1458their preferences.  We have determined the following collection of
     1459astyle options which achieve the many of the coding standard
     1460guidelines specified above.  Note that any of the listed options
     1461(always in the 'long' form) may be specified in the user's
     1462\code{.astylerc} file by dropping the leading dash.
     1463
     1464\begin{itemize}
     1465\item \code{--mode=c} - This option tells \code{astyle} to recognize
     1466  the source code as C code.
     1467
     1468\item \code{--indent-switches} - This option tells \code{astyle} to
     1469  indent the \code{case} statements in a \code{switch}.  Do not also
     1470  specify \code{--indent-cases}.
     1471
     1472\item \code{--indent-labels} - This option tells \code{astyle} to add
     1473  indentation to labels so they are indented one level less than the
     1474  current level.
     1475
     1476\item \code{--min-conditional-indent=0} - This option tells
     1477  \code{astyle} not to add indentation to successive lines of
     1478  multiple-line conditional statements.
     1479
     1480\item \code{--max-instatement-indent=20} - This option tells
     1481  \code{astyle} to limit the total amount of indentation to 20 spaces.
     1482
     1483\item \code{--pad=oper} - This option tells \code{astyle} to add
     1484  padding about binary operators.
     1485
     1486\item \code{--brackets=break} - This option tells \code{astyle} to
     1487  break brackets from their pre-block statements, dropping them to the
     1488  next line.
     1489
     1490\item \code{--convert-tabs} - This option tells \code{astyle} to
     1491  convert tabs into the equivalent number of space characters.
     1492
     1493\item \code{--indent=spaces=4} - This option tells \code{astyle} to
     1494  use 4 spaces per indent level.
     1495
     1496bibliographystyle{plain}
    14411497\bibliography{panstarrs}
    14421498
Note: See TracChangeset for help on using the changeset viewer.