GFire Developers Coding Convention

Some general rules making life and development with each other a bit easier ...

---

General:

• 1. Using glib if possible. Mixing it with stdlib makes no sense.
• 2. Creating functions for accessing data types (compare with glib; stick to the OOP-concept!) like at least "gfire_data *gfire_data_create();" and "void gfire_data_free(gfire_data *p_data);".
• 3. Splitting the code in one header/source file combination per task/struct (gfire_data.c/h, gfire_buddy.c/h, purple_interface.c/h, chat.c/h, clan.c/h, game_detection.c/h, ...).
• 4. Terminating compiler warnings if possible (e.g. no "int create_a_warning(int blah, void *blubb) { return blah; };") :).
• 5. Using const whenever no change to the variable is needed.
• 6. Using "//" for single line comments; "/**/" for multiline comments (well ... what else?).

Naming convention:

• 1. Any type or function names start with a lower case character.
• 2. Where there ought to be spaces in these names, there are underscores (e.g. my_function_x instead myFunctionX, etc. ...).
• 3. Structures are to be declared together with a typedef. The structure's name itself starts with an underscore, the according typedef has the same name, only excluding the first underscore.
• 4. Declarations or definitions of types, functions, etc. start in a new line.
• 5. Curly braces always get their own, new line.

Some examples:

A structure definition always looks like this pattern:

// maybe some other code
typedef struct _blahblah
{
 // some members
} blahblah;
// maybe some more code

A function definition always looks like this pattern:

// maybe some other code
some_data_type my_function( const type1 param1, const type2 param2 /*, maybe some_more_parameters*/ )
{
 do_stuff( param1, param2 );
 // dont provoke a warning by not using one of the parameters ;)
}
// more fresh code

... Thanks for sticking to these few principles! :-)