Tuxmino

Highly moddable free open source falling block puzzle game. Written in C.

Contributing

If you are interested in contributing to Tuxmino, that's great! Below is a link to TODO.md which is a list of all issues and things that haven't been implemented yet. Also make sure you read the Styling Guidelines below. Also if you contribute, please add yourself to the game credits in credits.c!

TODO.md

Styling Guidelines

General Guidelines

Indents should be 4 spaces.
Variable names should be descriptive and readable, dont use variable names like itmlst when you could instead write itemList.
Don't use confusing macros. I do not care that for loops can be turned into a macro, it is important that basic functionality like for-loops be easily recognizable. People dont know what loop() is, but everyone can easily recognize for (int i = 0; ...)
Line length should be kept within 120 characters, however this is not a hard limit.
2 line breaks between function declarations.
Whitespace after control flow statements. Example: for (), if (), while (). NOTE: Do NOT do this with regular function calls.
Do not define multiple variables on the same line. Things like int* var1, var2; can cause confusion.
/* This style of commenting */ is preferable to // this style
Else statements should be on their own line. Example:

/* Do this */
if (condition) {
    /* code */
}
else if (condition) {
    /* code */
}

/* DONT do this */
if (condition) {
    /* code */
} else if (condition) {
    /* code */
}

Naming Conventions

Do to the extensive use of the Raylib library in this project, the naming conventions are quite similar to Raylib's to avoid mixing different naming styles. However, some things are different. Here is a list of all of the naming conventions:

Code Element	Convention
Defines	ALL_CAPS
Macros	ALL_CAPS
Variables (all types)	camelCase
Pointers	Type* pointer
Floats	x.xf (ex: 10.0f)
Operators (all types)	Value1 + value2
Enum	TitleCase
Enum members	ALL_CAPS
Struct	TitleCase
Struct members	camelCase
Functions	camelCase
Function Params	camelCase

File Docstrings

At the top of every file should be a docstring stating:

The name of the file.
The purpose of the file.
The author of the file.
People who contributed to the file. Can be your real name, github username, or an email. You can also include a short summary of what you contributed to the file.
The date the file was created.
The date the file was last modified.
Dates should be expressed as MMM DD, YYYY (Jan 01, 2023)

Example:

/*
 * File: file.c
 * ------------
 * This is a file that does xyz, it should be used for xyz, etc.
 *
 * Original Author: John Doe
 * Contributors:
 *   - Tux: Added xyz
 * Date Created: MMM DD, YYYY
 * Last Modified: MMM DD, YYYY
 */

Functions

Functions should have descriptive names, and should use camelCase. The opening bracket for a function should be on its own line (this is only for functions, dont do this for if statements, loops, etc). Each function should have a small comment/docstring explaining what the function does. You do not need to go into detail on HOW the function works, only WHAT it does (or better yet, WHY its doing something). If the name of the function is super obvious, for example something like drawSquare(), you do not need to provide a docstring stating "This function draws a square". If a function doesn't need a docstring, you do not need to write one. All functions should have two line breaks in between them.

Example:

/*
 * This function does xyz
 */
void thisIsAFunction(int param)
{
    if (param == 3) {
        /* code */
    }
}


void superObviousFunction()
{
    /* code */
}


/*
 * This is another function with a docstring
 */
void anotherFunction()
{
    /* code */
}