mirror of
https://github.com/moparisthebest/curl
synced 2024-12-22 08:08:50 -05:00
more blurb
This commit is contained in:
parent
51d205b267
commit
27328281b7
@ -6,15 +6,16 @@
|
|||||||
|
|
||||||
To Think About When Contributing Source Code
|
To Think About When Contributing Source Code
|
||||||
|
|
||||||
This document is intended to offer some guidelines that can be useful to keep
|
This document is intended to offer some simple guidelines that can be useful
|
||||||
in mind when you decide to write a contribution to the project. This concerns
|
to keep in mind when you decide to contribute to the project. This concerns
|
||||||
new features as well as corrections to existing flaws or bugs.
|
new features as well as corrections to existing flaws or bugs.
|
||||||
|
|
||||||
Join the Community
|
Join the Community
|
||||||
|
|
||||||
Skip over to http://curl.haxx.se/mail/ and join the appropriate mailing
|
Skip over to http://curl.haxx.se/mail/ and join the appropriate mailing
|
||||||
list(s). Read up on details before you post questions. Read this file before
|
list(s). Read up on details before you post questions. Read this file before
|
||||||
you start sending patches!
|
you start sending patches! We prefer patches and discussions being held on
|
||||||
|
the mailing list(s), not sent to individuals.
|
||||||
|
|
||||||
The License Issue
|
The License Issue
|
||||||
|
|
||||||
@ -29,9 +30,9 @@ The License Issue
|
|||||||
|
|
||||||
What To Read
|
What To Read
|
||||||
|
|
||||||
Source code, the man pages, the INTERALS document, the TODO, the most recent
|
Source code, the man pages, the INTERNALS document, the TODO, the most recent
|
||||||
CHANGES. Just lurking on the libcurl mailing list is gonna give you a lot of
|
CHANGES. Just lurking on the libcurl mailing list is gonna give you a lot of
|
||||||
insights on what's going on right now.
|
insights on what's going on right now. Asking there is a good idea too.
|
||||||
|
|
||||||
Naming
|
Naming
|
||||||
|
|
||||||
@ -39,19 +40,24 @@ Naming
|
|||||||
names. It doesn't necessarily have to mean that you should use the same as in
|
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,
|
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
|
understandable and be named according to what they're used for. File-local
|
||||||
functions should be made static.
|
functions should be made static. We like lower case names.
|
||||||
|
|
||||||
|
See the INTERNALS document on how we name non-exported library-global symbols.
|
||||||
|
|
||||||
Indenting
|
Indenting
|
||||||
|
|
||||||
Please try using the same indenting levels and bracing method as all the
|
Please try using the same indenting levels and bracing method as all the
|
||||||
other code already does. It makes the source code a lot easier to follow if
|
other code already does. It makes the source code a lot easier to follow if
|
||||||
all of it is written using the same style. We don't ask you to like it, we
|
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! ;-)
|
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().
|
||||||
|
|
||||||
Commenting
|
Commenting
|
||||||
|
|
||||||
Comment your source code extensively. Commented code is quality code and
|
Comment your source code extensively using C comments (/* comment */), do not
|
||||||
enables future modifications much more. Uncommented code much more risk being
|
use C++ comments (// this style). Commented code is quality code and enables
|
||||||
|
future modifications much more. Uncommented code much more risk being
|
||||||
completely replaced when someone wants to extend things, since other persons'
|
completely replaced when someone wants to extend things, since other persons'
|
||||||
source code can get quite hard to read.
|
source code can get quite hard to read.
|
||||||
|
|
||||||
@ -69,6 +75,13 @@ Non-clobbering All Over
|
|||||||
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.
|
||||||
|
|
||||||
|
Platform Dependent Code
|
||||||
|
|
||||||
|
Use #ifdef HAVE_FEATURE to do conditional code. We avoid checking for
|
||||||
|
particular operting 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.
|
||||||
|
|
||||||
Separate Patches Doing Different Things
|
Separate Patches Doing Different Things
|
||||||
|
|
||||||
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
|
||||||
@ -94,6 +107,10 @@ Document
|
|||||||
small description of your fix or your new features with every contribution so
|
small description of your fix or your new features with every contribution so
|
||||||
that it can be swiftly added to the package documentation.
|
that it can be swiftly added to the package documentation.
|
||||||
|
|
||||||
|
The documentation is always made in man pages (nroff formatted) or plain
|
||||||
|
ASCII files. All HTML files on the web site and in the release archives are
|
||||||
|
generated from the nroff/ASCII versions.
|
||||||
|
|
||||||
Write Access to CVS Repository
|
Write Access to CVS Repository
|
||||||
|
|
||||||
If you are a frequent contributor, or have another good reason, you can of
|
If you are a frequent contributor, or have another good reason, you can of
|
||||||
|
Loading…
Reference in New Issue
Block a user