Insano-Pattern: Tuple Madness

Here at this blog I hope to be documenting all kinds coding tricks sure to keep you indispensable to your employers. This one's for the dynamic languages only: tuple madness.

The pattern is this:

Never return anything from a method call that is not wrapped in an array.

Do:

• Prefer returning many objects at once to creating a struct-like container for them.
• Return objects of extremely heterogenous types, sharing no ancestor class whatsoever.
• Use well-known mathematical sequences as type-indicating indices to your array, placing -- for example -- Orders on all Fibonacci numbers and Users on all perfect squares, with perfect squares taking precedence. Point out that this allows rapid < O(n) array traversal.
• Once, just once, return [[[]]] and parse it out as the true set-theoretic definition of the number 2.
  

Don't:

• Document your return types in comments.
• Return types in a consistent order. Use the handy-dandy shuffle function.
  
• Return a consistent number of objects. Different code paths should sometimes leave four objects, sometimes five.
  

If someone criticizes your code, tell them that:

• Your coding is LISPish, and that there is just nothing as beneficial to developer productivity as LISP and its powerfully productive list abstractions.
• You are taking advantage of duck typing and that you work twice as quickly as you did in the days of static programming.
• You are practicing defensive programming and making sure that no dreaded null pointer exception will ever be thrown again. You are doing this by enforcing a scrupulously consistent contracts on each method's return type, and that you really deserve a raise for all the debugging costs you are saving the company. (Note that this should not prevent you from returning nil wrapped in an array).
• Typing is just not Agile®. Finishing user story cards is all that counts.