Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.ï¿½ ï¿½ Brian W. Kernighan
He has the right to criticize, who has the heart to help - A. Lincon
Expressiveness is a first order concern of source code. If it isnt expressive don't do it. If one option is more expressive than another, choose the more expressive one.
enslave the 'new' or it will enslave you. New statements and imports are the agents of cohesion.
speak only interface
inheritance is a mechanism to support polymorphism not primarily code reuse. Prefer composition to inheritance.
Less is more, reduced api / instruction set is a fundimental pattern
one return statement per funtion - Return is not a flow control mechanism. It is a statement that expresses what should be returned for f(x).
dont use exceptions for flow control either. Its bad form. In addition, exception handlers are implemented on the stack. Stack unwinding is much more expensive then a branch. which doesnt need to be stack managed and may even be cached.
handle the exception / error as soon as possible
if your code is hard flow chart look again.
always cast with condifence - Dynamic casting is problematic and hard to debug when it fails. Put casting behind a controled interface. Don't propegate dynamic casts throughout the code
check for null now, avoid the headaches of meaningless errors later. If boundary checking is too expensive handle the error quickly and point out where the null might have come from. Its possible to move the check to a expensive location.
prefer event / messsage model
you cant prevent change, manage it.
prefer 'POJO': POJO Plain old java object. If you need to create remotable objects or attach other concerns wrap it. Business logic needs to live in the simplest form. Another example is COM components. Write you core logic in plain old C++ and wrap it with COM.
Simplicity is the key - Ockham's razor: any phenomenon should make as few assumptions as possible, eliminating, or 'shaving off', those that make no difference in the observable predictions of the explanatory hypothesis or theory. The principle is often expressed in Latin as the lex parsimoniae (law of succinctness): entia non sunt multiplicanda praeter necessitatem,which translates to: entities should not be multiplied beyond necessity.
complexity can be made simple by hiding it behind an interface
humans tend to build complexity by composing the simple