diff options
Diffstat (limited to 'CONTRIBUTE')
| -rw-r--r-- | CONTRIBUTE | 74 |
1 files changed, 0 insertions, 74 deletions
diff --git a/CONTRIBUTE b/CONTRIBUTE deleted file mode 100644 index 99cf2c53e..000000000 --- a/CONTRIBUTE +++ /dev/null @@ -1,74 +0,0 @@ - _ _ ____ _ - ___| | | | _ \| | - / __| | | | |_) | | - | (__| |_| | _ <| |___ - \___|\___/|_| \_\_____| - -CONTRIBUTE - -To Think About When Contributing Source Code - - This document is intended to offer some guidelines that can be useful to - keep in mind when you decide to write a contribution to the project. This - concerns new features as well as corrections to existing flaws or bugs. - -Naming - - Try using a non-confusing naming scheme for your new functions and variable - names. It doesn't necessarily have to mean that you should use the same as - in other places of the code, just that the names should be logical, - understandable and be named according to what they're used for. - -Indenting - - Please try using the same indenting levels and bracing method as all the - other code already does. It makes the source code a lot easier to follow if - all of it is written using the same style. I don't ask you to like it, I - just ask you to follow the tradition! ;-) - -Commenting - - Comment your source code extensively. I don't see myself as a very good - source commenter, but I try to become one. Commented code is quality code - and enables future modifications much more. Uncommented code much more risk - being completely replaced when someone wants to extend things, since other - persons' source code can get quite hard to read. - -General Style - - Keep your functions small. If they're small you avoid a lot of mistakes and - you don't accidentally mix up variables. - -Non-clobbering All Over - - When you write new functionality or fix bugs, it is important that you - don't fiddle all over the source files and functions. Remember that it is - likely that other people have done changes in the same source files as you - have and possibly even in the same functions. If you bring completely new - functionality, try writing it in a new source file. If you fix bugs, try to - fix one bug at a time and send them as separate patches. - -Separate Patches Doing Different Things - - It is annoying when you get a huge patch from someone that is said to fix 511 - odd problems, but discussions and opinions don't agree with 510 of them - or - 509 of them were already fixed in a different way. Then the patcher needs to - extract the single interesting patch from somewhere within the huge pile of - source, and that gives a lot of extra work. Preferably, all fixes that - correct different problems should be in their own patch with an attached - description exactly what they correct so that all patches can be selectively - applied by the maintainer or other interested parties. - -Document - - Writing docs is dead boring and one of the big problems with many open - source projects. Someone's gotta do it. It makes it a lot easier if you - submit a small description of your fix or your new features with every - contribution so that it can be swiftly added to the package documentation. - -Write Access to CVS Repository - - If you are a frequent contributor, or have another good reason, you can of - course get write access to the CVS repository and then you'll be able to - check-in all your changes straight into the CVS tree instead of sending all - changes by mail as patches. Just ask if this is what you'd want. |