| rdfs:comment
| - If you want to hack Freeciv, and want your patches to be accepted, it helps to follow some simple style rules. Yes, some of these are a bit nit-picky, but wars are fought over the silliest things...
* This style is used for all code in Freeciv. Freeciv gtk-clients use this style, not gtk style.
* Freeciv is mostly programmed in C, C89 with some C99 features. Qt parts are programmed in C++. Even C++ parts should have mostly consistent style with C parts, so where not otherwise noted, this guide applies to C++ parts too. Headers that are included to both C and C++ source files follow C style.
* C++-style comments (i.e., // comments) are forbidden in C code. They should be used for single-line comments in C++ code.
* Declaring variables in the middle of the scope is forbidden
- The coding style used will be similar to Vala itself[1] (which in turn is similar to gtk+) to keep consistency.
* Tabs rather than spaces.
* Tab width unspecified, but 4 works well.
* Hanging braces: blah { blahblah; }
* Cuddled else.
* Braces not necessary for single-line blocks.
* Variable and method identifiers in lowercase, words seperated by underscores.
* Type identifiers in CamelCase.
* Enum members and constants in ALL_CAPS, words seperated by underscores.
* C-style /* comments. */
* Hungarian notation not used.
* Variables often declared without type (i.e. "var").
* No line-length limit.
* Function-length limit of two screens - lets keep them small and readable.
* Space between method name and parameters' opening
- Because PvPGN is developed mainly on POSIX/Linux systems there are some things specific to this type of platform (like the line ending of all text/source files to be "Unix-style"). One thing which is overlooked by newbie coders is the "aesthetical" side of the code. It may not be so important to many people (which code on the idea "if it works then its good") but for us, coding on PvPGN is VERY important. When you are coding for PvPGN, PLEASE try to make your code look similar to already written code (this includes indenting, identifier names, etc...). Keeping the code look "the same" makes its reading a lot more easier so, finding bugs easier so coding better.
|
| abstract
| - Because PvPGN is developed mainly on POSIX/Linux systems there are some things specific to this type of platform (like the line ending of all text/source files to be "Unix-style"). One thing which is overlooked by newbie coders is the "aesthetical" side of the code. It may not be so important to many people (which code on the idea "if it works then its good") but for us, coding on PvPGN is VERY important. When you are coding for PvPGN, PLEASE try to make your code look similar to already written code (this includes indenting, identifier names, etc...). Keeping the code look "the same" makes its reading a lot more easier so, finding bugs easier so coding better. Other overlooked aspect for newbie coders is code replication. Please DON'T copy and paste code around !!! If you need to copy common functionality from some place, think about making some API of that functionality, put it in some classes and use it from both places. I repeat, DON'T replicate code. When allocating memory (or some other kind of resource like a file, etc) inside a function always free it (release the resource) in the same function before its exit (exceptions: the function returns the allocated memory/resource in which case the calling function should take care of the allocated memory; or the allocated memory is cached/stored somewhere to be used later, in which case you must make sure it will be free()d when not needed anymore). In the start-up code of any "external" function (function which may be called from other modules then the one containing it or a public method ) please check ALL the input parameters (you will notice how PvPGN already does that in such functions). In case of errors detected in such cases (and not only) code should "throw" an exception (see section 5.d). When developing code you should compile always with "all warnings" enabled and try to fix them (some warnings uncover real bugs), like for gcc use "-Wall". When running/testing the codes you should use a memory debugger like valgrind. For more details about how to run pvpgn check Coding Tools. To allocate/free memory use ONLY new/delete calls (this makes sure that out of memory condition is detected and nicely handled because in that case "new" automatically "throws" std::bad_alloc exception).
- The coding style used will be similar to Vala itself[1] (which in turn is similar to gtk+) to keep consistency.
* Tabs rather than spaces.
* Tab width unspecified, but 4 works well.
* Hanging braces: blah { blahblah; }
* Cuddled else.
* Braces not necessary for single-line blocks.
* Variable and method identifiers in lowercase, words seperated by underscores.
* Type identifiers in CamelCase.
* Enum members and constants in ALL_CAPS, words seperated by underscores.
* C-style /* comments. */
* Hungarian notation not used.
* Variables often declared without type (i.e. "var").
* No line-length limit.
* Function-length limit of two screens - lets keep them small and readable.
* Space between method name and parameters' opening parenthesis.
* Property "get", "set", "default" declaration all on one line, seperated by semicolons, if default implementations are used.
* If properties have implementations, then "get {", "set {" open new lines.
* Attributes on their own line.
* using prefixes (for example Gtk.Window) and no using;
* this. when it's unclear where an object comes from.
* Header at top of file contains: /* filename.vala * * Copyright (C) 20yy-20yy Copyright Holder * * License text. * * Author: * Programmer Name */
- If you want to hack Freeciv, and want your patches to be accepted, it helps to follow some simple style rules. Yes, some of these are a bit nit-picky, but wars are fought over the silliest things...
* This style is used for all code in Freeciv. Freeciv gtk-clients use this style, not gtk style.
* Freeciv is mostly programmed in C, C89 with some C99 features. Qt parts are programmed in C++. Even C++ parts should have mostly consistent style with C parts, so where not otherwise noted, this guide applies to C++ parts too. Headers that are included to both C and C++ source files follow C style.
* C++-style comments (i.e., // comments) are forbidden in C code. They should be used for single-line comments in C++ code.
* Declaring variables in the middle of the scope is forbidden (unless you are using C99 dynamic arrays and you need to check the size of the array before you declare it).
* Where variable is logically boolean, 'bool' type should be used even in C code. To make sure that the type is defined, include utility/support.h. In C code boolean values are uppercase macros 'TRUE' and 'FALSE'. In C++ code lowercase boolean values 'true' and 'false' should be used.
* Functions that take no arguments should be declared and defined with 'void' argument list in C code, and empty argument list in C++ code.
* C: int no_arguments(void); C++: int no_arguments();
* Use K&R indentation style with indentation 2 (if in doubt, use "indent -kr -i2 -l77", but beware that that will probably mangle the _() macros used to mark translated strings and the brace style for iteration macros).
* Do not re-indent areas of code you are not modifying or creating.
* Here are the most important formatting rules:
* Lines are at most 77 characters long, including the terminating newline.
* The tab width is 8 spaces for tabs that already exist in the source code (this is just so that old code will appear correctly in your editor). However, tabs should be avoided in newly written code.
* The indentation is 2 spaces per level for all new code; do not use tabs for any kind of indentation. The one exception to this is if you are just adding one line to a set of lines that are already indented with some strange mix of tabs and spaces; in this case you may use the same indentation as the surrounding lines.
* Do not add more than 2 empty lines between any sections in the code.
* Spaces are inserted before and after operators: instead of int a,b,c; if(foo<=bar){ c=a+b; } use int a, b, c; if (foo <= bar) { c = a + b; } Also note the space between "if" and the bracket.
* Switch statement case labels are aligned with the enclosing "switch": switch (value) { case MY_VALUE1: do_some_stuff(value); break; case MY_VALUE2: { int value2 = value + 5; do_some_other_stuff(value2); } break; }
* In the rare case that you actually use goto, the label should be all capitals and "out-dented" in the block in which it is contained: static int frob(int n) { int i, j; for (i = 0; i < n; i++) { for (j = i; j < n; j++) { if (some_condition(i, j)) { goto EXIT_LOOP; } } } EXIT_LOOP: return 123; }
* If a function prototype exceeds 77 characters on one line, you should put the return value type and storage specifier on the line immediately above it: static const struct incredibly_long_structure_name * get_a_const_struct_incredibly_long_structure_name(int id);
* If arguments in a function prototype or a function call cause the line to exceed 77 characters, they should be placed on the following line and lined up with spaces to the column after the '(': void some_function(const struct another_really_long_name *arln, int some_other_argument);
* If the line is still too long for some reason, you may place the arguments two indentation levels on the next line: a_very_awkward_long_function_name(some_argument, "A really long string that would have to be cut up."); But you should try to avoid this situation, either by naming your functions/types/variables more succinctly, or by using helper variables or functions to split the expression over a number of lines.
* An empty line should be placed between two separate blocks of code.
* Place operators at the beginning of a line, not at the end. It should be if ((a && b) || c) { instead of if ((a && b) || c) {
|
![[RDF Data]](/fct/images/sw-rdf-blue.png)