Under construction

API design guidelines

The following guidelines are meant to make the user experience more pleasant. They are aimed to help the user make use of existing tools and increase productivity. As a first guideline, keep in mind that somebody other than you will use your code.

Object orientation

Object orientation is a design approach that attempts to model real world objects in the code.
Try to think in objects.
Make use of the visibility of objects.
Hide your implementation from the user.
On the other hand, not every class needs to have a set of private data members with a full-blown set of Setters and Getters. It is ok to have a class with only public data members.
Rule: What belongs together logically should be handled together
Example:

Optimization

Optimization obfuscates code. It also forces you to change your intuitive approach.
Rule: First, write your code. Then profile it. Then, if necessary, optimize it.

Status codes

In the good old Fortran and C days, obscure statuscodes and bitfields were common sight. While it is true that your code should be optimized at the persistence level, make sure you include definitions of your statuscodes in the API. The use of EnumSet is encouraged.

good code 

bad code

"Overloaded Operators"

It is very confusing to have members like add(Object o1, Object o2) as members of the classes. This is counter-intuitive. Either there ought to be a supporter class with static members only, or the member of the type class expects only one argument.
So:
vec1.add(vec1, vec2);
vec1.add(vec2);
import static x.y.add; add(vec1, vec2);

Using strings to access parameters

While I admit there are situations where it is hard to avoid using strings to pass information between functions (e.g. event.put/event.get), most of the time this is a horrible idea. Look at the RadLengths class as an example. There is nothing dynamic about this class, all radiation lengths are constant and therefore determined at compile time. Besides imposing an unnecessary overhead of string comparison, the compiler cannot check if the string is spelled correctly. I really fail to comprehend why we don't use symbolic constants for these kinds of things. Be it in terms of static ints or enums, but at least something that can be checked at compile time rather than runtime. Again, that way we can even take advantage of code-completion.

Thank you for your consideration
Jan