Question

After reading ‘What’s your/a good limit for cyclomatic complexity?‘, I realize many of my colleagues were quite annoyed with this new QA policy on our project: no more 10 cyclomatic complexity per function.

Meaning: no more than 10 ‘if’, ‘else’, ‘try’, ‘catch’ and other code workflow branching statement. Right. As I explained in ‘Do you test private method?‘, such a policy has many good side-effects.

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 ‘Aspect-oriented programming‘ approach for logs).

myLogger.info('A String'); myLogger.fine('A more complicated String'); ... 

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 log parameters (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!

So QA came back and urged our programmers to do conditional logging. Always.

if(myLogger.isLoggable(Level.INFO) { myLogger.info('A String'); if(myLogger.isLoggable(Level.FINE) { myLogger.fine('A more complicated String'); ... 

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!

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 really part of said complexity of that function…

How would you address this situation ?
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.

---

Thank you for all the answers.
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)
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 obligation to use conditional logging, hence the actual issue of artificial increase of ‘cyclomatic complexity’…)

I now get the ‘variadic function’ point advanced by some of you (thank you John).
Note: a quick test in java6 shows that my varargs function 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.

I have now posted my experience on this topic.
I will leave it there until next Tuesday for voting, then I will select one of your answers.
Again, thank you for all the suggestions 🙂

Answer 1

In Python you pass the formatted values as parameters to the logging function. String formatting is only applied if logging is enabled. There’s still the overhead of a function call, but that’s minuscule compared to formatting.

log.info ('a = %s, b = %s', a, b) 

You can do something like this for any language with variadic arguments (C/C++, C#/Java, etc).

---

This isn’t really intended for when the arguments are difficult to retrieve, but for when formatting them to strings is expensive. For example, if your code already has a list of numbers in it, you might want to log that list for debugging. Executing mylist.toString() will take a while to no benefit, as the result will be thrown away. So you pass mylist as a parameter to the logging function, and let it handle string formatting. That way, formatting will only be performed if needed.

---

Since the OP’s question specifically mentions Java, here’s how the above can be used:

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)

The trick is to have objects that will not perform expensive computations until absolutely needed. This is easy in languages like Smalltalk or Python that support lambdas and closures, but is still doable in Java with a bit of imagination.

Say you have a function get_everything(). It will retrieve every object from your database into a list. You don’t want to call this if the result will be discarded, obviously. So instead of using a call to that function directly, you define an inner class called LazyGetEverything:

public class MainClass {     private class LazyGetEverything {          @Override         public String toString() {              return getEverything().toString();          }     }      private Object getEverything() {         /* returns what you want to .toString() in the inner class */     }      public void logEverything() {         log.info(new LazyGetEverything());     } } 

In this code, the call to getEverything() is wrapped so that it won’t actually be executed until it’s needed. The logging function will execute toString() on its parameters only if debugging is enabled. That way, your code will suffer only the overhead of a function call instead of the full getEverything() call.