4 Use DEBUG_0() only for temporary debugging i.e. not in code in the repository.
5 The user will then not see irrelevant debug output when the default
6 debug level = 0 is used.
9 If the first word of the message is "error" or "warning" (case insensitive)
10 the message will be color-coded appropriately.
16 For use with the GTKInspector to provide a visual indication of where objects are declared.
18 Sample command line call:
19 GTK_DEBUG=interactive src/geeqie
21 --------------------------------------------------------------------------------
23 GPL header, in every file, like this:
26 * \short Short description of this file.
30 * Optionally detailed description of this file
35 * This file is a part of Geeqie project (http://www.geeqie.org/).
36 * Copyright (C) 2008 - 2016 The Geeqie Team
38 * This program is free software; you can redistribute it and/or modify it
39 * under the terms of the GNU General Public License as published by the Free
40 * Software Foundation; either version 2 of the License, or (at your option)
43 * This program is distributed in the hope that it will be useful, but WITHOUT
44 * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
45 * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for
49 --------------------------------------------------------------------------------
53 If referencing a Geeqie GitHub issue, include the issue number in the summary line.
54 Start with a short summary in the first line (without a dot at the end) followed
57 If referencing a Geeqie GitHub issue, include a hyperlink to the GitHub issue page
59 Use whole sentences begins with Capital letter. For each
60 modification use new line. Or you can write the theme, colon and then every
61 change on new line, begin with "- ".
63 See also: http://www.tpope.net/node/106
69 There was the bug that something was wrong. I fixed it.
72 - the interface was modified
73 - new functions were added
75 Also please use your full name and a working e-mail address as author for any contribution.
77 --------------------------------------------------------------------------------
82 Names of variables & functions: small_letters
83 of defines: CAPITAL_LETTERS
85 Try to use explicit variable and function names.
87 Try not to use macros.
88 Use EITHER "struct foo" OR "foo"; never both
106 if (<cond_very_very_very_very_very_very_very_very_very_long> &&
107 <cond2very_very_very_very_very_very_very_very_very_long>)
120 for (i = 0; i <= 10; i++)
130 gint bar(<var_def>, <var_def>, <var_def>)
136 return 0; // i.e. SUCCESS; if error, you must return minus <err_no>
146 Pragma: (Indentation 2 spaces)
150 # define _(String) (String)
151 #endif /* ENABLE_NLS */
157 --------------------------------------------------------------------------------
159 Use spaces around every operator (except ".", "->", "++" and "--");
160 unary operator '*' and '&' are missing the space from right;
161 (and also unary '-').
162 As you can see above, parentheses are closed to inside, i.e. " (blah blah) "
163 In "function(<var>)" there are no space before '('.
164 You MAY use more tabs/spaces than you OUGHT TO (according to this CodingStyle), if
165 it makes your code nicer in being vertically indented.
166 Variables declarations should be followed by a blank line and should always be
167 at the start of the block.
169 --------------------------------------------------------------------------------
171 Use glib types when possible (ie. gint and gchar instead of int and char).
172 Use glib functions when possible (ie. g_ascii_isspace() instead of isspace()).
173 Check if used functions are not deprecated.
175 --------------------------------------------------------------------------------
179 Use American, rather than British English, spelling. This will facilitate consistent
180 text searches. User text may be translated via the en_GB.po file.
182 To document the code use the following rules to allow extraction with doxygen.
183 Do not save with comments. Not all comments have to be doxygen comments.
185 - Use C comments in plain C files and use C++ comments in C++ files for one line
187 - Use '/**' (note the two asterisks) to start comments to be extracted by
188 doxygen and start every following line with " *".
189 - Use '@' to indicate doxygen keywords/commands (see below).
190 - Use the '@deprecated' command to tell if the function is subject to be deleted
191 or to a complete rewrite.
195 To document functions or big structures:
197 * @brief This is a short description of the function.
199 * This function does ...
201 * @param x1 This is the first parameter named x1
202 * @param y1 This is the second parameter named y1
203 * @return What the function returns
204 * You can extend that return description (or anything else) by indenting the
205 * following lines until the next empty line or the next keyword/command.
206 * @see Cross reference
209 To document members of a structure that have to be documented (use it at least
210 for big structures) use the '/**<' format:
211 int counter; /**< This counter counts images */
213 Document TODO or FIXME comments as:
220 For further documentation about doxygen see
221 http://www.stack.nl/~dimitri/doxygen/manual.html. For the possible commands you
222 can use see http://www.stack.nl/~dimitri/doxygen/commands.html.
224 But in case just think about that the documentation is for other developers not
225 for the end user. So keep the focus.
227 The file ./scripts/doxygen-help.sh may be used to integrate access to the
228 Doxygen files into a code editor.