title: Conditional logging with minimal cyclomatic complexity
body: <p>After reading "<a href="http://web.archive.org/web/20090117062700/http://stackoverflow.com:80/questions/20702/whats-youra-good-limit-for-cyclomatic-complexity" rel="noreferrer">What’s your/a good limit for cyclomatic complexity?</a>", I realize many of my colleagues were quite annoyed with this new <a href="http://en.wikipedia.org/wiki/Quality_assurance" rel="noreferrer">QA</a> policy on our project: no more 10 <a href="http://en.wikipedia.org/wiki/Cyclomatic_complexity" rel="noreferrer">cyclomatic complexity</a> per function.</p>
  
  <p>Meaning: no more than 10 'if', 'else', 'try', 'catch' and other code workflow branching statement. Right. As I explained in '<a href="https://stackoverflow.com/questions/105007/do-you-test-private-method#105114">Do you test private method?</a>', such a policy has many good side-effects.</p>
  
  <p>But: At the beginning of our (200 people - 7 years long) project, we were happily logging (and no, we can not easily delegate that to some kind of '<a href="http://en.wikipedia.org/wiki/Aspect-oriented_programming" rel="noreferrer">Aspect-oriented programming</a>' approach for logs).</p>
  
  <pre><code>myLogger.info("A String");
  myLogger.fine("A more complicated String");
  ...
  </code></pre>
  
  <p>And when the first versions of our System went live, we experienced huge memory problem not because of the logging (which was at one point turned off), but because of the <em>log parameters</em> (the strings), which are always calculated, then passed to the 'info()' or 'fine()' functions, only to discover that the level of logging was 'OFF', and that no logging were taking place!</p>
  
  <p>So QA came back and urged our programmers to do conditional logging. Always.</p>
  
  <pre><code>if(myLogger.isLoggable(Level.INFO) { myLogger.info("A String");
  if(myLogger.isLoggable(Level.FINE) { myLogger.fine("A more complicated String");
  ...
  </code></pre>
  
  <p>But now, with that 'can-not-be-moved' 10 cyclomatic complexity level per function limit, they argue that the various logs they put in their function is felt as a burden, because each "if(isLoggable())" is counted as +1 cyclomatic complexity!</p>
  
  <p>So if a function has 8 'if', 'else' and so on, in one tightly-coupled not-easily-shareable algorithm, and 3 critical log actions... they breach the limit even though the conditional logs may not be <em>really</em> part of said complexity of that function...</p>
  
  <p>How would you address this situation ?<br>
  I have seen a couple of interesting coding evolution (due to that 'conflict') in my project, but I just want to get your thoughts first.</p>
  
  <hr>
  
  <p>Thank you for all the answers.<br>
  I must insist that the problem is not 'formatting' related, but 'argument evaluation' related (evaluation that can be very costly to do, just before calling a method which will do nothing)<br>
  So when a wrote above "A String", I actually meant aFunction(), with aFunction() returning a String, and being a call to a complicated method collecting and computing all kind of log data to be displayed by the logger... or not (hence the issue, and the <em>obligation</em> to use conditional logging, hence the actual issue of artificial increase of 'cyclomatic complexity'...)</p>
  
  <p>I now get the '<a href="http://en.wikipedia.org/wiki/Variadic_function" rel="noreferrer">variadic</a> function' point advanced by some of you (thank you John).<br>
  Note: a quick test in java6 shows that my <a href="http://java.sun.com/j2se/1.5.0/docs/guide/language/varargs.html" rel="noreferrer">varargs function</a> does evaluate its arguments before being called, so it can not be applied for function call, but for 'Log retriever object' (or 'function wrapper'), on which the toString() will only be called if needed. Got it.</p>
  
  <p>I have now posted my experience on this topic.<br>
  I will leave it there until next Tuesday for voting, then I will select one of your answers.<br>
  Again, thank you for all the suggestions :)</p>