David Brownell <david-b@pacbell.net>:
[openocd.git] / doc / manual / style.txt
1 /** @page styleguide Style Guides
2
3 The goals for each of these guides are:
4 - to produce correct code that appears clean, consistent, and readable,
5 - to allow developers to create patches that conform to a standard, and
6 - to eliminate these issues as points of future contention.
7
8 Some of these rules may be ignored in the spirit of these stated goals;
9 however, such exceptions should be fairly rare.
10
11 The following style guides describe a formatting, naming, and other
12 conventions that should be followed when writing or changing the OpenOCD
13 code:
14
15 - @subpage styletcl
16 - @subpage stylec
17 - @subpage styleperl
18 - @subpage styleautotools
19
20 In addition, the following style guides provide information for
21 providing documentation, either as part of the C code or stand-alone.
22
23 - @subpage styledoxygen
24 - @subpage styletexinfo
25 - @subpage stylelatex
26
27 Feedback would be welcome to improve the OpenOCD guidelines.
28
29  */
30 /** @page styletcl TCL Style Guide
31
32 OpenOCD needs to expand its Jim/TCL Style Guide.
33
34 Many of the guidelines listed on the @ref stylec page should apply to
35 OpenOCD's Jim/TCL code as well.
36
37  */
38 /** @page stylec C Style Guide
39
40 This page contains guidelines for writing new C source code for the
41 OpenOCD project.
42
43 @section styleformat Formatting Guide
44
45 - remove any trailing white space at the end of lines.
46 - use TAB characters for indentation; do NOT use spaces.
47 - displayed TAB width is 4 characters.
48 - use Unix line endings ('\\n'); do NOT use DOS endings ('\\r\\n')
49 - limit adjacent empty lines to at most two (2).
50 - remove any trailing empty lines at the end of source files
51 - do not "comment out" code from the tree; instead, one should either:
52   -# remove it entirely (Subversion can retrieve the old version), or
53   -# use an @c \#if/\#endif block.
54
55 Finally, try to avoid lines of code that are longer than than 72-80 columns:
56
57 - long lines frequently indicate other style problems:
58   - insufficient use of static functions, macros, or temporary variables
59   - poor flow-control structure; "inverted" logical tests
60 - a few lines may be wider than this limit (typically format strings), but:
61   - all C compilers will concatenate series of string constants.
62   - all long string constants should be split across multiple lines.
63
64 @section stylenames Naming Rules
65
66 - most identifiers must use lower-case letters (and digits) only.
67   - macros must use upper-case letters (and digits) only.
68   - OpenOCD identifiers should NEVER use @c MixedCaps.
69 - structure names must end with the '_s' suffix.
70 - typedef names must end with the '_t' suffix.
71 - use underline characters between consecutive words in identifiers
72   (e.g. @c more_than_one_word).
73
74 @section stylec99 C99 Rules
75
76 - inline functions
77 - @c // comments -- in new code, prefer these for single-line comments
78 - trailing comma allowed in enum declarations
79 - designated initializers (@{ .field = value @})
80 - variables declarations may be mixed with code
81 - new block scopes for selection and iteration statements
82
83 @section stylefunc Functions
84
85 - static inline functions should be prefered over macros:
86 @code
87 /** do NOT define macro-like functions like this... */
88 #define CUBE(x) ((x) * (x) * (x))
89 /** instead, define the same expression using a C99 inline function */
90 static inline int cube(int x) { return x * x * x; }
91 @endcode
92 - Functions should be declared static unless required by other modules
93   - define static functions before first usage to avoid forward declarations.
94 - Functions should have no space between its name and its parameter list:
95 @code
96 int f(int x1, int x2)
97 {
98         ...
99         int y = f(x1, x2 - x1);
100         ...
101 }
102 @endcode
103
104  */
105 /** @page styledoxygen Doxygen Style Guide
106
107 The following sections provide guidelines for OpenOCD developers
108 who wish to write Doxygen comments in the code or this manual.
109 For an introduction to Doxygen documentation,
110 see the @ref primerdoxygen.
111
112 @section styledoxyblocks Doxygen Block Selection
113
114 Several different types of Doxygen comments can be used; often,
115 one style will be the most appropriate for a specific context.
116 The following guidelines provide developers with heuristics for
117 selecting an appropriate form and writing consistent documentation
118 comments.
119
120 -# use @c /// to for one-line documentation of instances.
121 -# for documentation requiring multiple lines, use a "block" style:
122 @verbatim
123 /**
124  * @brief First sentence is short description.  Remaining text becomes
125  * the full description block, where "empty" lines start new paragraphs.
126  *
127  * One can make text appear in @a italics, @b bold, @c monospace, or
128  * in blocks such as the one in which this example appears in the Style
129  * Guide.  See the Doxygen Manual for the full list of commands.
130  *
131  * @param foo For a function, describe the parameters (e.g. @a foo). 
132  * @returns The value(s) returned, or possible error conditions.
133  */
134 @endverbatim
135   -# The block should start on the line following the opening @c /**.
136   -# The end of the block, \f$*/\f$, should also be on its own line.
137   -# Every line in the block should have a @c '*' in-line with its start:
138     - A leading space is required to align the @c '*' with the @c /** line.
139     - A single "empty" line should separate the function documentation
140       from the block of parameter and return value descriptions.
141     - Except to separate paragraphs of documentation, other extra
142       "empty" lines should be removed from the block.
143   -# Only single spaces should be used; do @b not add mid-line indentation.
144 -# If the total line length will be less than 72-80 columns, then
145   - The @c /**< form can be used on the same line.
146   - This style should be used sparingly; the best use is for fields:
147     @code int field; /**< field description */ @endcode
148
149 @section styledoxyall Doxygen Style Guide
150
151 The following guidelines apply to all Doxygen comment blocks:
152
153 -# Use the @c '\@cmd' form for all doxygen commands (do @b not use @c '\\cmd').
154 -# Use symbol names such that Doxygen automatically creates links:
155   -# @c function_name() can be used to reference functions
156     (e.g. flash_set_dirty()).
157   -# @c struct_name::member_name should be used to reference structure
158     fields in the documentation (e.g. @c flash_driver_s::name).
159   -# URLS get converted to markup automatically, without any extra effort.
160   -# new pages can be linked into the heirarchy by using the @c \@subpage
161     command somewhere the page(s) under which they should be linked:
162   -# use @c \@ref in other contexts to create links to pages and sections.
163 -# Use good Doxygen mark-up:
164   -# '\@a' (italics) should be used to reference parameters (e.g. <i>foo</i>).
165   -# '\@b' (bold) should be used to emphasizing <b>single</b> words.
166   -# '\@c' (monospace) should be used with <code>file names</code> and
167   <code>code symbols</code>, so they appear visually distinct from
168   surrounding text.
169   -# To mark-up multiple words, the HTML alternatives must be used.
170 -# Two spaces should be used when nesting lists; do @b not use '\\t' in lists.
171 -# Code examples provided in documentation must conform to the Style Guide.
172
173 @section styledoxytext Doxygen Text Inputs
174
175 In addition to the guidelines in the preceding sections, the following
176 additional style guidelines should be considered when writing
177 documentation as part of standalone text files:
178
179 -# Text files must contain Doxygen at least one comment block:
180   -# Documentation should begin in the first column (except for nested lists).
181   -# Do NOT use the @c '*' convention that must be used in the source code.
182 -# Each file should contain at least one @c \@page block.
183   -# Each new page should be listed as a \@subpage in the \@page block
184   of the page that should serve as its parent.
185   -# Large pages should be structure in parts using meaningful \@section
186   and \@subsection commands.
187 -# Include a @c \@file block at the end of each Doxygen @c .txt file to
188   document its contents:
189   - Doxygen creates such pages for files automatically, but no content
190     will appear on them for those that only contain manual pages.
191   - The \@file block should provide useful meta-documentation to assist
192     techincal writers; typically, a list of the pages that it contains.
193   - For example, the @ref styleguide exists in @c doc/manual/style.txt,
194     which contains a reference back to itself.
195 -# The \@file and \@page commands should begin on the same line as
196    the start of the Doxygen comment:
197 @verbatim
198 /** @page pagename Page Title
199
200 Documentation for the page.
201
202  */
203 /** @file
204
205 This file contains the @ref pagename page.
206
207  */
208 @endverbatim
209
210 For an example, the Doxygen source for this Style Guide can be found in
211 @c doc/manual/style.txt, alongside other parts of The Manual.  
212
213  */
214 /** @page styletexinfo Texinfo Style Guide
215
216 The User's Guide is there to provide two basic kinds of information.  It
217 is a guide for how and why to use each feature or mechanism of OpenOCD.
218 It is also the reference manual for all commands and options involved
219 in using them, including interface, flash, target, and other drivers.
220 At this time, it is the only user-targetted documentation; everything
221 else is addressing OpenOCD developers.
222
223 There are two key audiences for the User's Guide, both developer based.
224 The primary audience is developers using OpenOCD as a tool in their
225 work, or who may be starting to use it that way.  A secondary audience
226 includes developers who are supporting those users by packaging or
227 customizing it for their hardware, installing it as part of some software
228 distribution, or by evolving OpenOCD itself.  There is some crossover
229 between those audiences.  We encourage contributions from users as the
230 fundamental way to evolve and improve OpenOCD.  In particular, creating
231 a board or target specific configuration file is something that many
232 users will end up doing at some point, and we like to see such files
233 become part of the mainline release.
234
235 General documentation rules to remember include:
236
237 - Be concise and clear.  It's work to remove those extra words and
238   sentences, but such "noise" doesn't help readers.
239 - Make it easy to skim and browse.  "Tell what you're going to say,
240   then say it".  Help readers decide whether to dig in now, or
241   leave it for later.
242 - Make sure the chapters flow well.  Presentations should not jump
243   around, and should move easily from overview down to details.
244 - Avoid using the passive voice.
245 - Address the reader to clarify roles ("your config file", "the board you
246   are debugging", etc.); "the user" (etc) is artificial.
247 - Use good English grammar and spelling.  Remember also that English
248   will not be the first language for many readers.  Avoid complex or
249   idiomatic usage that could create needless barriers.
250 - Use examples to highlight fundamental ideas and common idioms.
251 - Don't overuse list constructs.  This is not a slide presentation;
252   prefer paragraphs.
253
254 When presenting features and mechanisms of OpenOCD:
255
256 - Explain key concepts before presenting commands using them.
257 - Tie examples to common developer tasks.
258 - When giving instructions, you can \@enumerate each step both
259   to clearly delineate the steps, and to highlight that this is
260   not explanatory text.
261 - When you provide "how to use it" advice or tutorials, keep it
262   in separate sections from the reference material.
263 - Good indexing is something of a black art.  Use \@cindex for important
264   concepts, but don't overuse it.  In particular, rely on the \@deffn
265   indexing, and use \@cindex primarily with significant blocks of text
266   such as \@subsection.  The \@dfn of a key term may merit indexing.
267 - Use \@xref (and \@anchor) with care.  Hardcopy versions, from the PDF,
268   must make sense without clickable links (which don't work all that well
269   with Texinfo in any case).  If you find you're using many links,
270   read that as a symptom that the presentation may be disjointed and
271   confusing.
272 - Avoid font tricks like \@b, but use \@option, \@file, \@dfn, \@emph
273   and related mechanisms where appropriate.
274
275 For technical reference material:
276
277 - It's OK to start sections with explanations and end them with
278   detailed lists of the relevant commands.
279 - Use the \@deffn style declarations to define all commands and drivers.
280   These will automatically appear in the relevant index, and those
281   declarations help promote consistent presentation and style.
282    - It's a "Command" if it can be used interactively.
283    - Else it's a "Config Command" if it must be used before the
284      configuration stage completes.
285    - For a "Driver", list its name.
286    - Use BNF style regular expressions to define parameters:
287      brackets around zero-or-one choices, parentheses around
288      exactly-one choices.
289    - Use \@option, \@file, \@var and other mechanisms where appropriate.
290    - Say what output it displays, and what value it returns to callers.
291    - Explain clearly what the command does.  Sometimes you will find
292      that it can't be explained clearly.  That usually means the command
293      is poorly designed; replace it with something better, if you can.
294    - Be complete:  document all commands, except as part of a strategy
295      to phase something in or out.
296    - Be correct:  review the documentation against the code, and
297      vice versa.
298 - Alphabetize the \@defn declarations for all commands in each
299   section.
300 - Keep the per-command documentation focussed on exactly what that
301   command does, not motivation, advice, suggestions, or big examples.
302   When commands deserve such expanded text, it belongs elsewhere.
303   Solutions might be using a \@section explaining a cluster of related
304   commands, or acting as a mini-tutorial.
305 - Details for any given driver should be grouped together.
306
307 The User's Guide is the first place most users will start reading,
308 after they begin using OpenOCD.  Make that investment of their time
309 be as productive as possible.  Needing to look at OpenOCD source code,
310 to figure out how to use it is a bad sign, though it's OK to need to
311 look at the User's guide to figure out what a config script is doing.
312
313  */
314 /** @page stylelatex LaTeX Style Guide
315
316 This page needs to provide style guidelines for using LaTeX, the
317 typesetting language used by The References for OpenOCD Hardware.
318 Likewise, the @ref primerlatex for using this guide needs to be completed.
319
320  */
321 /** @page styleperl Perl Style Guide
322
323 This page provides some style guidelines for using Perl, a scripting
324 language used by several small tools in the tree:
325
326 -# Ensure all Perl scripts use the proper suffix (@c .pl for scripts, and 
327    @c .pm for modules)
328 -# Pass files as script parameters or piped as input:
329   - Do NOT code paths to files in the tree, as this breaks out-of-tree builds.
330   - If you must, then you must also use an automake rule to create the script.
331 -# use @c '#!/usr/bin/perl' as the first line of Perl scripts.
332 -# always <code>use strict</code> and <code>use warnings</code>
333 -# invoke scripts indirectly in Makefiles or other scripts:
334 @code
335 perl script.pl
336 @endcode
337
338 Maintainers must also be sure to follow additional guidelines:
339 -# Ensure that Perl scripts are committed as executables:
340   - Use "<code>chmod +x script.pl</code>"
341     @a before using "<code>svn add script.pl</code>", or
342   - Use "<code>svn ps svn:executable '*' script.pl</code>"
343     @a after using "<code>svn add script.pl</code>".
344
345  */
346 /** @page styleautotools Autotools Style Guide
347
348 This page contains style guidelines for the OpenOCD autotools scripts.
349
350 The following guidelines apply to the @c configure.in file:
351 - Better guidelines need to be developed, but until then...
352 - Use good judgement.
353
354 The following guidelines apply to @c Makefile.am files:
355 -# When assigning variables with long lists of items:
356   -# Separate the values on each line to make the files "patch friendly":
357 @code
358 VAR = \
359         value1 \
360         value2 \
361         ...
362         value9 \
363         value10
364 @endcode
365  */
366 /** @file
367
368 This file contains the @ref styleguide pages.  The @ref styleguide pages
369 include the following Style Guides for their respective code and
370 documentation languages:
371
372 - @ref styletcl
373 - @ref stylec
374 - @ref styledoxygen
375 - @ref styletexinfo
376 - @ref stylelatex
377 - @ref styleperl
378 - @ref styleautotools
379
380  */