-
Notifications
You must be signed in to change notification settings - Fork 28
Code Style
My coding style is a lot different than the one from SUN, but since the whole project uses it, it looks bad if I add a small part which doesn’t fit the standard. Also, this is MY personal coding style and I like it this way. If you don’t like it, okay, but this is still my project. It doesn’t matter how appealing a style looks to you, as long as you stick to it.
-
Only tabs - NO spaces… At least for indentation.
-
No empty lines at the end of a file.
-
Inside the code they can be used to make it structured but are not necessary if no other rules apply. However, there shall never be two empty lines next to each other.
-
After every code block (method, class, multiline if, etc.), there has to be an empty line if it is not the end of another block.
if(true)
{
if(true)
{
//...
}
}
if(true)
{
//...
}-
Exception: case, catch, finally, else/else if and do…while
-
No empty lines between import groups, but after package and before class declaration.
package test; import bla; import bla.bla; import test; import test.bla; public class Test //...
-
When creating a new code block, being it the body of a method or an if, the block should always start on the next line, not on the same. This includes the curly brackets which start the block.
public void test()
{
if(true)
{
//...
}
}
-
Exception being: Anonymous classes and array initializers.
int[] array = new int[] { 1, 2, 3 };
Runnable runnable = new Runnable() {
//...
};
-
before and after every operator, except ++, — (and - only if it used to make a negative number not to substract).
-
No space before any kind of parentheses, except if other rules apply.
@Annotation(bla = "a")
public void test()
{
int[] j = new int[] { -1, 1 + 1, ++1, 2--, 5 - 1 };
}
test();
-
After every comma there needs to be a space.
call(var, var2);
-
Before first and after last element when initializing an array.
int[] array = new int[] { 1, 2 };
-
No space inside or after cast.
RemotePlayer player = (RemotePlayer)entity;
-
Each annotation has it’s own line, except parameter annotations.
-
No wrapping after certain character amount.
-
One enum constant per line.
@Annotation
@Annotation2
public boolean m_test;
public void annotated(@Param int inTest)
{
}
public void methodWithALongNameAndManyParameters(int inThisIsTheFirstParameter, int inThisIsTheSecondParameter, int inThisIsTheThirdParameterAndItsStillNotWrapped)
{
}
public enum MyEnum
{
FIRST,
SECOND
}
-
The content of a code block is always indented one more than it’s parent.
-
This includes the content of a case statement.
-
should have brackets around it.
-
Don’t chain more than two together.
int x = (y == 0 ? 1 : 2);
-
Please don’t make them longer than needed.
-
camelCase
-
Getter for booleans can and in most of the cases should start with "should…" or "is…" instead of "get…".
-
"m_" + camelCase name. (e.g. m_variableName) ("Why?" you might ask. Well, m is short for member and the underscore just makes it more readable.)
-
This does not apply for variables inside a class that is considered a "struct". Those have the same convention as method variables.