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
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
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
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
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
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
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:
projects / platform / upstream / curl.git / blobdiff