Coding standards for Clash of Civilizations


Coding standards guidelines for the Clash of Civilizations code

Prepared by Laurent Di Cesare, May 2005


First of all, you can check the Style and coding guidelines written by Gary in his design.html document.

Summary of Gary's guidelines

To sum up what he says in this section of his document. For details and rationales, refer to the aforementioned document:

Indenting should be done, with the same indent in a given file. Indents should use spaces rather than tabs. 2 spaces is common, 4 or anything else is acceptable as long as: always use indents and always use the same size indents. A subsidiary rule is always indent on continuation lines.

Always limit the line length to 80 columns. Not 81 or 82.

Always complete the JavaDocs comments.

Use meaningful names, not jpanel1, jpanel2 or other automatically generated names.

Don't use abbreviations.

Don't use really long names.

Don't use Hungarian notation.

Don't put comments at the end of the line.

You are welcome to use //------ lines to break the code into more digestible sections.

In case there are any who don't realize, Java class names, by convention, start with a capital letter. Constant names are all upper case. All other variables start with a lower case letter. Always.

And finally, keep everything small. A method longer than 30 lines should be looked at askance, as should a class file longer than 500 lines. These are guidelines, not rules, sometimes longer ones are needed. But make sure that they really are needed.

I should mention the "curly bracket on the same line" versus the "curly bracket on the next line" difference of opinion. So, I have now mentioned it.

Avoid unchecked exceptions.

Use ArrayList and HashMap rather than Vector and Hashtable.

Avoid using Cloneable.

Avoid Observer/Observable classes (but do use the pattern if needed).

Don't put static data into interfaces.

Serialization is not used in Clash.

Other guidelines

Other guidelines in Clash include:

Floating point variables

Floating point variables are of type float, not double.
This is mostly because of size constraints, and the extra precision is not really needed. This has been a rule since I joined the project, so it's quite old.

imports
Use import package.*; rather than import package.class;.

Using class specific imports has several advantages:

Package imports on the other hand has some advantages:

Overall, using package imports makes it easier for the developper to work, but harder on the compiler. But the compiler's time is free while the developper's is scarce. An example follows:

When you want to replace the line

  Collection list = new LinkedList();
by
  Collection list = new ArrayLsit(12);
If you used import java.util.*; you are done.
If you used import java.util.LinkedList; you must also
  1. Check whether LinkedList is used elsewhere in the file.
  2. If it is not, delete the import line.
  3. Add an import java.util.ArrayList line if needed.
This means you have about three times as much work to do just to replace one class by another. This makes refactoring much longer and harder, and I do not see any benefits to it.