Contributors guide

Git Guidelines

Write good git messages. Summarize what your commit does and why you are committing this change. Ideally, your commit messages should conform to the following format. Summary of what your commit does.

Describe in more detail what your commit does.  Why does your commit do this?

Are there any issues that this commit relates to?

Summary:

• Do use verbs such as fix and add to describe the commit.
• Do keep it under 51 characters.
• Don’t use past tense verbs to describe the commit.

Description:

• Do describe what your commit actually does.
• Do describe why your commit does this.
• Don’t exceed 72 characters per lines.
• Don’t exceed more than two paragraph in details.

Project Structure

Organize your code. Good code organization makes understanding the code 10 times easier. The basic structure for the project is as follows.

Structure:

• build - Put all the release builds here.
• tests - This is where all the unit tests go.
• support - This is where files support scons go.
• src - The actual source code goes in here.

In addition to the basic project structure, code structure is just as important to understanding the actual code. All code should be under the src directory with its documentation found in docs. In addition all code should be further organized into subfolders whose name is the name of the module.

For example, the connection part of the Authentication module would be found under src/auth/connection.h and src/auth/connection.c. All code, with the exception of main.c, should follow this convention.

Media should be stored under a corresponding subdirectory under src/media. For example, all images would be stored under src/media/images and all music under src/media/music.

Tests should follow the same folder structure as both code and documentation. With one test per “pair” of code. For example, the connection part of the Authentication module would be found under tests/auth/connection.c.

C Guidelines

Naming

• Each distinct section should get its own folder, a header of the same name, and have a server header and a client header (for example, network/server.h).
• The prefix for all exposed symbols will be il, and then the first letter of module name will follow, then an underscore, then the name of the symbol. Example: ilG_newShape
• We will be using lowercase for structs, camelCase for functions, lower_case for variables, and UPPER_CASE for constants.

Source

• K&R style
• When defining a struct, use typedef struct name { /* … */ } name; so that we don’t have to spam “struct” everywhere.
• If you are only using a struct definition from any given header, it is preferable to just use a struct definition instead of including a whole header (ex. using 'struct il_positionable' instead of including all of positionable.h)
• Don’t forget header guards (no #prama’s) :|
• Don’t use char* for strings. Use (il_String) { LEN, DATA } - Null terminated strings are so 1969.