| 16 | Before implementing new stuff drop a note on the Voyager mailing list. |
| 17 | This prevents duplicate efforts if someone else is already working on the things you |
| 18 | have in mind. In addition ML discussions make sure any patches fit into the overall |
| 19 | architecture of the desktop. |
| 20 | |
| 21 | === Patch policy === |
| 22 | |
| 23 | Bug fixes may go directly into the tree. Enhancements of classes (like new methods) or |
| 24 | completely new classes will first have a test drive for some time to make sure they fit |
| 25 | in. Enhancements should be coded as replacement classes not as direct patches to existing |
| 26 | classes. If you need to patch an exisiting class to get something done it's likely |
| 27 | your design isn't optimal. This doesn't mean enhancement of existing classes to |
| 28 | support new features in subclasses are rejected. If it turns out your enhancements are |
| 29 | working flawlessly they will go into the main tree which means they will be added |
| 30 | directly to the classes in question. |
| 31 | |
| 32 | === Documentation === |
| 33 | |
| 34 | Every new feature (e.g. methods) '''must''' be documented in the source using doxygen |
| 35 | tags. See the existing source for examples.[[BR]] |
| 36 | Comment your code thouroughly even if you think comments are not necessary because anyone |
| 37 | should be able to understand your code. |
| 38 | |
| 39 | |
| 40 | Patches without proper comments or doxygen documentation will be rejected without discussion. |
| 41 | |
| 42 | === Coding style === |
| 43 | |
| 44 | Function and method names:: |
| 45 | Names are not build with underscores like in the GLib toolkit. Instead uppercase letters |
| 46 | are used to separate name parts: |
| 47 | |
| 48 | {{{ dont_use_this_as_a_name();}}} |
| 49 | |
| 50 | {{{ thisIsCorrect(); }}} |
| 51 | |
| 52 | The first letter is always lowercase. Note that this is true for all functions and methods in NOM.[[BR]] |
| 53 | In pure C libraries the first letter is usually uppercase. |
| 54 | |
| 55 | Variables:: |
| 56 | Use verbose variables. i, j, k was ok last century but today we have compilers supporting really long |
| 57 | variable names. Verbose names make it easier for newcomers to understand your code. Prepend your variables |
| 58 | with a meaningful marker (e.g. i for int). |
| 59 | |
| 60 | {{{ |
| 61 | #!c |
| 62 | int main(int argc, char *argv[]) |
| 63 | { |
| 64 | /* This is not ok */ |
| 65 | gint i, k; |
| 66 | char* p; |
| 67 | |
| 68 | printf("Hello World\n"); |
| 69 | ... |
| 70 | } |
| 71 | }}} |
| 72 | |
| 73 | {{{ |
| 74 | #!c |
| 75 | int main(int argc, char *argv[]) |
| 76 | { |
| 77 | /* Use something like this */ |
| 78 | gint iLoop, iNumberOfItems; |
| 79 | gulong ulSize; |
| 80 | char* pString; |
| 81 | |
| 82 | printf("Hello World\n"); |
| 83 | ... |
| 84 | } |
| 85 | }}} |
| 86 | |