1 $VER OpenBOOPSI Project Style Guide 1.1 (4.5.99)
4 OpenBOOPSI Project Style Guide
15 2.3 Single line comments
16 2.4 Multi line comments
29 This is a brief guide on recommended source code formatting style
30 for the OpenBOOPSI Project classes. Every source file added to this
31 project should conform as close as possible to the rules given in
32 this document to mantain consistency within the source tree.
34 It might happen that you're already used to a different coding
35 style. Yes, we all understand well that changing your style can be
36 frustrating for any programmer. But the need to keep the source
37 code style consistent is more important than each one's habits.
38 No one will blame you if you don't strictly follow these
39 guidelines, but we will be glad if you do.
46 Comment as much as you can. Other programmers will read your
47 sources and since most of them will have different knowledge of
48 Amiga programming and/or different ways to do a certain thing they
49 may not understand the purpose or the inner working of some of your
50 code, so try to explain what you are doing. Obviously avoid comments
51 such as "now open a window" right above a OpenWindow() function call.
55 Comments must be written in english.
57 2.3 SINGLE LINE COMMENTS
59 Single line comments should follow the ANSI C syntax, i.e.
60 using the "/* */" construct. C++ comments must not be used
61 because not all C compilers do support them.
63 2.4 MULTI LINE COMMENTS
65 Comments spanning over multiple lines should be formatted this way:
67 /* This is a very very very
68 * very very long comment!
76 Tabs are four spaces wide.
80 There should be a space after commas.
82 There should never be a space after a * when it's used with pointers,
85 ULONG *pointer = NULL;
88 There should be a blank space around operators, e.g.:
94 the only exceptions are prefix and postfix ++ and -- operators,
100 Before a parenthesis there should never be blank spaces if
101 it follow a keyword or a function name. e.g.
104 DoMethod(); /* also good */
105 while () /* wrong! */
106 yourfunction (); /* also wrong! */
110 After the #include block and after the #define one there should be
113 Between the declaration of the global variables and the beginning of
114 the code there should be two empty lines.
116 Between the end of a function and the next one there should be three
119 Any code block enclosed in braces should be preceded by an empty line.
120 An open brace should be on a line by itself. After a closing brace there
121 should be one empty line, except when another closing brace follows. e.g.
140 /* the following is wrong! */
150 4. NAMING CONVENTIONS
154 Everything related to the classes (methods, functions, etc.) should
155 have a prefix (two or three letter maximum) that recalls the name of
156 the class. i.e. if your class is called "BananaSplit" its methods
157 should be called something like BSM_SHAKE, its attributes should look
158 like BSA_SugarSpuns, etc.
162 Method functions should obviously follow the general rule and have
163 the above mentioned prefix, e.g.:
167 Function names should have the first letters of each word
168 forming their names capitalized, like system's one. e.g.:
170 MyWonderfulFunction()
174 Variables name must be in english and must have a meaning! Please
175 avoid names such as "foobar" or "dummy"! We hate them!
178 struct Window *win; /* these are good */
181 struct BitMap *dummy1; /* these are wrong! */
182 struct RastPort *dummy2;
184 Names of local variables should be all in lowercase. Global
185 variables should have their initials uppercase.