CONTRIBUTE: moved out code style to a separate document

 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

 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