ChunkPS/Coding Style

Introduction
This page is dedicated to how the code should look. Basically, it should be consistent with the rest of the code, and use the UNIX LF endings (Windows users need to get a text editor or IDE that supports LF line endings, Mac and Linux/UNIX users should be fine). This page is subject to change throughout development, so if something doesn't look quite right, check this page first before changing it.

Git
Basic git commit formatting can be found here: tbaggery.com

This isn't super important, but it makes it easier for the ChunkPS dev team to see what was done.

Issue Tracker
ChunkPS is going to use GitHub's Issue Tracker until a separate bug tracker can be set up. The issue tracker will be used to follow Bug Reports, Merge Requests, and so forth. The Issue Tracker will also have labels (like Bug, Feature, ect) so that eyeing over them will be easier for everyone.

Branches
It is recommended that any changes of the ChunkPS code be done in a separate branch, since the master branch is usually the latest commit, and things tend to get ugly if you change things in master after upstream master updates. More of that will be covered in another section.

Style
Like craftd, ChunkPS has the same general guidelines for coding style with a few exceptions. They are:
 * LF line endings. I said this before, but it's important to use LF line endings. Those who don't will be sacrificed to the Enderdragon.
 * If your IDE or text editor has Tab->Space support, set it to 4. If not, use 4 spaces for a tab. Again, sacrificed to Enderdragon otherwise.
 * As a general rule, limit C code to 80/100-column lines if able to.
 * Don't have abbreviated variable or method names, it's a pain in the ass to read. Overly descriptive names are also frowned on, so if it cannot be summed up to at least five words, it's too long.
 * Brackets on the same line are highly preferred. It makes the code look cleaner and is easier to read.

Variable Naming Convention

 * Packet Structure:

Internal Documentation
Methods, structs, and unions should have Doxygen/JavaDoc style documentation.