CONTRIBUTE: moved out code style to a separate document

diff --git a/docs/CONTRIBUTE b/docs/CONTRIBUTE
index 9e74d468a684c8958b7ecaa0fbc5126d85ca6328..9e84175ba708082a6730e31a2f7d6a46336a731c 100644 (file)
--- 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
@@ -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