ChunkPS/Coding Style

Jump to: navigation, search


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.


Basic git commit formatting can be found here:

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.


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.


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.
int cps_SendChunkToAll(SVChunk* chunk); //Good
int cps_DblTplChunk(SVDouble* nmbr, SVInteger* nmbr2); //Not Good
int cps_ThisIsAReallyLongAndPainfullMethodToType(SVInteger* nmbr); //May you be sacrificed to the Enderdragon
  • Brackets on the same line are highly preferred. It makes the code look cleaner and is easier to read.

Variable Naming Convention

  • Packet Structure:
typedef union _SVPacketName {
    struct {
        char stuff;
    } request;
    struct {
        char stuff;
    } response;
} SVPacketName;

Internal Documentation

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

 * Check if a coordinate pair exists within a rectangle struct.
 * @remarks Scope: public
 * @param rectangle pointer to a rectangle struct
 * @param x the x coordinate
 * @param y the y coordinate
 * @return true if the point is within the rectange, false otherwise