Lines Matching refs:a
4 This is a description of the Datalight Coding Style intended for third parties
6 DDSS Coding Guidelines, but only contains a subset of the content which is most
14 in a loop; and avoid having more than one return from a function (single point
19 Beyond MISRA-C, Datalight has a standard coding style. Most aspects of this
44 /* This is a single-line comment.
48 /* This is a multi-line comment. It is a comment that spans multiple
66 In all C code (.c/.h), use a tab width of four spaces, and use soft tabs (in
67 other words, tabs are expanded to spaces). In Makefiles, use hard tabs and a
81 types, structures, files, etc. For Doxygen tags, use '@' instead of a backslash
108 a requirement).
110 on a separate line.
111 - Generally each variable should be declared on a separate line. This promotes
112 readability, and facilitates having a comment for each variable.
115 closing brace which ends a function and the Doxygen comment which starts the
122 are never omitted, even if the braces contain only a single statement.
136 /* This is a single-line comment.
140 /* This is a multi-line comment. It is a comment that spans multiple
155 - There is usually a single blank line preceding the comment, however if the
162 Comments where the /* and */ are on the same line may be used in a few places:
170 It is OK for such comments to exceed the 80 character margin by a small amount,
182 module-scope (outside of a function)
183 - Comments which are outside of a function
246 Note that, like anything else between curly brackets, the contents of a switch
281 There are a few exceptions on both sides of the issue. Generally comments
283 120 character length by a large margin, if it makes the code more understandable
293 Any code which displays TTY style output, whether on a screen or a terminal,
353 a | An array
360 the "a" and "p" modifiers is completely appropriate (and expected).
364 - The "p" pointer modifier must be used such that a variable which is a pointer
365 to a pointer uses multiple "p" prefixes. A general rule-of-thumb is that the
373 Declare a variable in the narrowest scope in which it is meaningful.
374 Unnecessarily declaring all variables at the beginning of a function, where they
378 When multiple blocks of code share a variable, but not its value, declare the
381 For example, if two separate blocks contain loops indexed by a variable ulIndex
382 declare it separately in each block rather than declaring it once in a wider
386 failure to initialize the variable in the second block. If there is a single