...
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 Enum, EnumSet and EnumMapis encouraged.
| |
Code Block |
---|
good code | enum MyClassFlags {doThingX, doThingY, doThingZ};
|
| Code Block |
---|
int obscureFlag;
...
xy.setObscureFlag(3); // {color:red}NEVER hardcode numbers like this !!!{color} | Code Block |
---|
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, design it to look like this:
...
...
or Code Block |
---|
import static x.y.add; add(vec1, vec2); |
| Code Block |
---|
vec1.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
JanStrings should be used for input/output operations. They are slow to parse and cannot be checked for typos at compile time.
Using them to set flags and parameters is not recommended.