title: Favorite (Clever) Defensive Programming Best Practices
body: <p>If you had to choose your <strong>Favorite</strong> (clever) techniques for defensive coding, what would they be?  Although my current languages are Java and Objective-C (with a background in C++), feel free to answer in any language.  Emphasis here would be on <em>clever</em> defensive techniques other than those that 70%+ of us here already know about.  So now it is time to dig deep into your bag of tricks.</p>
  
  <p>In other words try to think of other than this <strong>uninteresting</strong> example:</p>
  
  <ul>
  <li><code>if(5 == x)</code> <strong>instead of</strong> <code>if(x == 5)</code>:  to avoid unintended assignment</li>
  </ul>
  
  <p>Here are some examples of some <strong>intriguing</strong> best defensive programming practices (language-specific examples are in Java):</p>
  
  <p><strong>- Lock down your variables until you know that you need to change them</strong></p>
  
  <p>That is, you can declare <em>all</em> variables <code>final</code> until you know that you will need to change it, at which point you can remove the <code>final</code>. One commonly unknown fact is that this is also valid for method params:</p>
  
  <pre><code>public void foo(final int arg) { /* Stuff Here */ }
  </code></pre>
  
  <p><strong>- When something bad happens, leave a trail of evidence behind</strong></p>
  
  <p>There are a number of things you can do when you have an exception: obviously logging it and performing some cleanup would be a few.  But you can also leave a trail of evidence (e.g. setting variables to sentinel values like "UNABLE TO LOAD FILE" or 99999 would be useful in the debugger, in case you happen to blow past an exception <code>catch</code>-block).</p>
  
  <p><strong>- When it comes to consistency: the devil is in the details</strong></p>
  
  <p>Be as consistent with the other libraries that you are using.  For example, in Java, if you are creating a method that extracts a range of values make the lower bound <em>inclusive</em> and the upper bound <em>exclusive</em>.  This will make it consistent with methods like <code>String.substring(start, end)</code> which operates in the same way.  You'll find all of these type of methods in the Sun JDK to behave this way as it makes various operations including iteration of elements consistent with arrays, where the indices are from Zero (<em>inclusive</em>) to the length of the array (<em>exclusive</em>). </p>
  
  <p>So what are some favorite defensive practices of yours?</p>
  
  <p><strong>Update: If you haven't already, feel free to chime in.  I am giving a chance for more responses to come in before I choose the <em>official</em> answer.</strong></p>