generic-library/curl
1
0
Fork 0
Code Issues Pull Requests Releases Wiki Activity

CONTRIBUTE: moved out code style to a separate document

Browse Source
This commit is contained in:
Daniel Stenberg 2016-03-14 10:31:00 +01:00
parent 303bf719ff
commit 1b3d736ae3
1 changed files with 17 additions and 62 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

79
docs/CONTRIBUTE
View File

@ -15,18 +15,13 @@
1.2 License 1.2 License
1.3 What To Read 1.3 What To Read
2. cURL Coding Standards 2. Write a good patch
2.1 Naming 2.1 Follow code style
2.2 Indenting 2.2 Non-clobbering All Over
2.3 Commenting 2.3 Write Separate Patches
2.4 Line Lengths 2.4 Patch Against Recent Sources
2.5 General Style 2.5 Document
2.6 Non-clobbering All Over 2.6 Test Cases
2.7 Platform Dependent Code
2.8 Write Separate Patches
2.9 Patch Against Recent Sources
2.10 Document
2.11 Test Cases
3. Pushing Out Your Changes 3. Pushing Out Your Changes
3.1 Write Access to git Repository 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 list is gonna give you a lot of insights on what's going on right now. Asking
there is a good idea too. 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 When writing C code, follow the CODE_STYLE already established in the
names. It doesn't necessarily have to mean that you should use the same as in project. Consistent style makes code easier to read and mistakes less likely
other places of the code, just that the names should be logical, to happen.
understandable and be named according to what they're used for. File-local
functions should be made static. We like lower case names.
See the INTERNALS document on how we name non-exported library-global 2.2 Non-clobbering All Over
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
When you write new functionality or fix bugs, it is important that you don't 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 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 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. fix one bug at a time and send them as separate patches.
2.7 Platform Dependent Code 2.3 Write Separate Patches
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
It is annoying when you get a huge patch from someone that is said to fix 511 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 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 Also, separate patches enable bisecting much better when we track problems in
the future. 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 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 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 if you get the most up-to-date sources from the git repository, but the
latest release archive is quite OK as well! 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 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 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 ASCII files. All HTML files on the web site and in the release archives are
generated from the nroff/ASCII versions. 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 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 features are working as they're supposed to. To maintain this situation and