RDINB Development Principles

[resplin]

Obsolete Pages{{Obsolete}}

The official documentation is at: http://docs.alfresco.com

RDINB

• 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
  

• remember the worse is better principle
  

http://www.ai.mit.edu/docs/articles/good-news/subsection3.2.1.html

• 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
  

• Nature renders simplicity by hiding complexity (quarks -> interface: strong forces -> particles --> iterface stronger forces -> molecules -> interfaces: shape -> cells -> inteface: cell signals -> organs -> interface inputs and outputs -> body -> interface: senses
  

• in nature the interfaces become more simple, mechanical, less options and permutations but the power increases 
  

• never set out with a solution seeking a problem..
  

other interesting thoughts

• 'If the brain were so simple we could understand it, we would be so simple we couldnt'--Lyall Watson