Contributing to EntityAPI

If you wish to add a specific feature to EntityAPI or just want to help us, then feel free to fork the repo and start hacking into it. We are open for suggestions and improvements.

To contribute to the project you need to follow our guidelines.

First of all:

Coding Conventions

Coding conventions are very important in an API. They define the usage API and the code-level. If everyone who commits code simply ignores these rules, then EntityAPI wouldn't exist today.

We mostly follow the standard coding conventions defined by Oracle (http://www.oracle.com/technetwork/java/javase/documentation/codeconvtoc-136057.html)

We do make a few exeptions, and for your comfort, we will be summing them up here:

Fields

When naming fields you can either choose between lowerCamelCase or just make it all UPPERCASE where you replace spaces by a "_".

Most of the fields should be uppercase. Basically, when there's one field in the class that is completly uppercase, then all other fields should be too. No matter there are 900 fields in lowerCamelcase and 1 completly UPPERCASE, you still will need to rename the 900 fields.

Final fields should always be UPPERCASE.

Here is an example:

public class MyAwesomeClass {

    private final Object SOME_OBJECT;

    public MyAwesomeClass() {
        this.SOME_OBJECT = new Object();
    }
}

(PS: Fields should never be named with the Hungarian notation)

Methods

Methods always need to be lowerCamelCase. We do not accept any code that doesn't follow these guidelines. Unlike with fields we are very clear about this. We won't do in discussion about this, how good your code may be, no lowerCamelCase = no pull.

Here's an example of lowerCamelCase:

public void doSomethingReallyCool() {
    // Do something cool
}

Classes

Class names must always follow the UpperCamelCase pattern. We only accept names with AlphaNumeric chars. Like the name 'UpperCamelCase' suggest, the first character of a class should always be uppercase.

Example:

public class MyAwesomeClass {

}

Spacing etc.

When coding a method the '{' should always be on the same line as the method. (Seperated by a space)

Example:

public class CoolClass {

    public void myCoolMethod() { 

    }
}

Like in the example, the class declaration and method should be seperated by a new line, but the last '}' of the class and of the method shouldn't be seperated by a new line.

// SOMEONE IMPROVE THIS PART

Editing core files. Working with Minecraft internals and messing with our code

Editing the core files means that you edit some of our most important classes. Eg: the classes located in io.snw.entityapi.entities. Please don't edit this code, if you do decide to edit them then please don't waste our time and make it something cool. You should also stay away from the build-in reflection api and nbt-lib. If you PR some really usefull code then we can negotiate if we pull or not.

As for working with the Minecraft internals, we provide a usefull reflection api, which we assume you will use. If you need any help on the reflection api then feel free to join the dev channel and ask there. Code with any malicious intend will not get pulled and will get you on the blacklist (aka banlist).

You are free to edit any of our code as long as it contributes a usefull feature. Adding pointless stuff to a class just to be able to say "I contributed to that" will get you on the list and don't count on your code ever getting pulled. In no way you can add your name to the collaborators list or plugin authors (located in plugin.yml). If we find you a valuable contributor then we will add you ourself. Asking for it will whipe out every chance to ever be part of it.