Merge pull request #118 from alex/document-c-style-guide

Document our style guide for C bindings

1 files changed, 44 insertions, 2 deletions

diff --git a/docs/contributing.rst b/docs/contributing.rst
index 2d8fceeb..b125d1af 100644
--- a/docs/contributing.rst
+++ b/docs/contributing.rst
@@ -20,8 +20,8 @@ devastating, ``cryptography`` has a strict code review policy:
 * Patches must *never* be pushed directly to ``master``, all changes (even the
   most trivial typo fixes!) must be submitted as a pull request.
 * A committer may *never* merge their own pull request, a second party must
-  merge their changes. If multiple people work on a pull request, the merger
-  may not be any of them.
+  merge their changes. If multiple people work on a pull request, it must be
+  merged by someone who did not work on it.
 * A patch which breaks tests, or introduces regressions by changing or removing
   existing tests should not be merged. Tests must always be passing on
   ``master``.
@@ -50,6 +50,48 @@ Additionally, every Python code file must contain
 
     from __future__ import absolute_import, division, print_function
 
+C bindings
+----------
+
+When binding C code with ``cffi`` we have our own style guide, it's pretty
+simple.
+
+Don't name parameters:
+
+.. code-block:: c
+
+    // Good
+    long f(long);
+    // Bad
+    long f(long x);
+
+Don't include stray ``void`` parameters:
+
+.. code-block:: c
+
+    // Good
+    long f();
+    // Bad
+    long f(void);
+
+Wrap lines at 80 characters like so:
+
+.. code-block:: c
+
+    // Pretend this went to 80 characters
+    long f(long, long,
+           int *)
+
+Include a space after commas between parameters:
+
+.. code-block:: c
+
+    // Good
+    long f(int, char *)
+    // Bad
+    long f(int,char *)
+
+
 Documentation
 -------------