# Contributing to Goxel

Please read this file first before making a pull request to Goxel.


## CLA

In your first pull request, you must add your name in a CLA file in
'doc/cla/individual'.  This gives me the right to release special version of
Goxel under a commercial licence.  It doesn't change the license of the current
code.  See:
https://github.com/guillaumechereau/goxel/blob/master/doc/cla/sign-cla.md
For more information about that.


## Coding style

Try to follow the code style I used for Goxel, as I am unlikely to merge a pull
request that doesn't.  The coding style is almost the one used by the linux
kernel, but using four spaces for indentation, and I also accept typedef.  When
in doubt, just look at other part of the code.  The most important rules are:

- Use 4 spaces indentations.  No tabs characters anywhere in the code.

- 80 columns max line width.

- No trailing white space.

- function and variable names all in lowercase, with underscore to separate
  parts if needed:

      int nb_block; // Good
      int nbBlock;  // Bad

- K&R style braces (opening brace on same line):

      if (something) {
          ...
      } else {
          ...
      }

- Except for functions, where we put the opening brace on the next line:

      int my_func(void)
      {
          ...
          return 0;
      }

- I also accept exceptions to the K&R braces for multi line conditions
  (but that should be avoided if possible by making the condition shorter):

      if (a_very_long_condition ||
          that_uses_several_lines)
      {
          ...
      }

- No space between function and argument parenthesis:

      func(10, 20) // Good
      func (10, 20) // BAD!


- One space after keywords, except `sizeof`:

      if (something) // Good
      if(something)  // BAD

- One space around binary operators, no space after unary operators and
  before postfix operators.

      x = 10 + 20 * 3; // Good
      x = 10+20*3; // BAD
      x++;  // Good
      x ++; // BAD
      y = &x; // Good
      y = & x; // VERY BAD

- Use 'C' style variable declarations:

      int *x; // Good
      int* x; // BAD

- Put all the variable declarations on top of the function, so that we can
  see them all at the same place.


## Git commit style

- Keep the summary line under about 50 characters.

- The rest of the commit message separated by a blank line.  Wrap lines at
  72 characters.

- Try to separate the commits into smaller logical parts, so it is easier to
  review them independently.
