diff options
Diffstat (limited to 'docs/CONTRIBUTE')
| -rw-r--r-- | docs/CONTRIBUTE | 85 |
1 files changed, 20 insertions, 65 deletions
diff --git a/docs/CONTRIBUTE b/docs/CONTRIBUTE index c6ea9773..9e84175b 100644 --- a/docs/CONTRIBUTE +++ b/docs/CONTRIBUTE @@ -15,18 +15,13 @@ 1.2 License 1.3 What To Read - 2. cURL Coding Standards - 2.1 Naming - 2.2 Indenting - 2.3 Commenting - 2.4 Line Lengths - 2.5 General Style - 2.6 Non-clobbering All Over - 2.7 Platform Dependent Code - 2.8 Write Separate Patches - 2.9 Patch Against Recent Sources - 2.10 Document - 2.11 Test Cases + 2. Write a good patch + 2.1 Follow code style + 2.2 Non-clobbering All Over + 2.3 Write Separate Patches + 2.4 Patch Against Recent Sources + 2.5 Document + 2.6 Test Cases 3. Pushing Out Your Changes 3.1 Write Access to git Repository @@ -42,13 +37,13 @@ 1.1 Join the Community - Skip over to http://curl.haxx.se/mail/ and join the appropriate mailing + Skip over to https://curl.haxx.se/mail/ and join the appropriate mailing list(s). Read up on details before you post questions. Read this file before you start sending patches! We prefer patches and discussions being held on the mailing list(s), not sent to individuals. Before posting to one of the curl mailing lists, please read up on the mailing - list etiquette: http://curl.haxx.se/mail/etiquette.html + list etiquette: https://curl.haxx.se/mail/etiquette.html We also hang out on IRC in #curl on irc.freenode.net @@ -87,48 +82,15 @@ list is gonna give you a lot of insights on what's going on right now. Asking there is a good idea too. -2. cURL Coding Standards +2. Write a good patch -2.1 Naming +2.1 Follow code style - 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. File-local - functions should be made static. We like lower case names. + When writing C code, follow the CODE_STYLE already established in the + project. Consistent style makes code easier to read and mistakes less likely + to happen. - See the INTERNALS document on how we name non-exported library-global - symbols. - -2.2 Indenting - - Use the same indenting levels and bracing method as all the other code - already does. It makes the source code easier to follow if all of it is - written using the same style. We don't ask you to like it, we just ask you to - follow the tradition! ;-) This mainly means: 2-level indents, using spaces - only (no tabs) and having the opening brace ({) on the same line as the if() - or while(). - - Also note that we use if() and while() with no space before the parenthesis. - -2.3 Commenting - - Comment your source code extensively using C comments (/* comment */), DO NOT - use C++ comments (// this style). Commented code is quality code and enables - future modifications much more. Uncommented code risk having to be completely - replaced when someone wants to extend things, since other persons' source - code can get quite hard to read. - -2.4 Line Lengths - - We write source lines shorter than 80 columns. - -2.5 General Style - - Keep your functions small. If they're small you avoid a lot of mistakes and - you don't accidentally mix up variables etc. - -2.6 Non-clobbering All Over +2.2 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 @@ -137,14 +99,7 @@ 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. -2.7 Platform Dependent Code - - Use #ifdef HAVE_FEATURE to do conditional code. We avoid checking for - particular operating systems or hardware in the #ifdef lines. The - HAVE_FEATURE shall be generated by the configure script for unix-like systems - and they are hard-coded in the config-[system].h files for the others. - -2.8 Write Separate Patches +2.3 Write Separate Patches 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 @@ -158,14 +113,14 @@ Also, separate patches enable bisecting much better when we track problems in the future. -2.9 Patch Against Recent Sources +2.4 Patch Against Recent Sources Please try to get the latest available sources to make your patches against. It makes the life of the developers so much easier. The very best is if you get the most up-to-date sources from the git repository, but the latest release archive is quite OK as well! -2.10 Document +2.5 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 @@ -176,7 +131,7 @@ ASCII files. All HTML files on the web site and in the release archives are generated from the nroff/ASCII versions. -2.11 Test Cases +2.6 Test Cases Since the introduction of the test suite, we can quickly verify that the main features are working as they're supposed to. To maintain this situation and @@ -203,7 +158,7 @@ You need to first checkout the repository: - git clone https://github.com/bagder/curl.git + git clone https://github.com/curl/curl.git You then proceed and edit all the files you like and you commit them to your local repository: |