| | 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 | |