So there you are digging and sifting through mounds of source code and console logs in XCode or Android Studio or even ADB wondering how on earth you are going to track down this bug before you ship this next iteration release to a customer. Your pulse quickens as erroneous lines fly past you with none of the information you need. That’s when you have the startling revelation that log messages have little value without some meaningful data and context.
Log messages have little value without some meaningful data and context! [Source @Metova] Click to tweet!
There are a few types of log messaging styles that as a developer I have come to cringe at the sight of when I see them. There’s the overly chatty log message that is eager to tell you the same repetitive information senselessly, the cryptic “this sounds important but it’s too vague to be of use” message, or the message that is no longer relevant and is just a relic from the early development process who’s sole purpose is to throw you off the trail of much more vital data.
I’ve come to set some personal standards that I’ve found have made debugging much easier and have really helped me. First, let’s start with cutting down on chatty logs. I think every developer has put in a sanity check like this before:
private void someMethod() { Log.d(TAG, “Hit someMethod”);}
That is perfectly cool and even on my soap box I will admit that I do that during development too, but once I see it work I go back and remove it. What I have found to be more useful is back tracking and seeing if we even get to the part where that method was supposed to be called…for example:
private void someMethodCallingAnotherMethod(){ if(someCondition) { // Do something Log.d(TAG, “ someCondition was true”); } else { Log.d(TAG, “ someCondition was false”); someMethod(); }}
This serves to make sure it’s not an issue with the calling logic. Of course with lifecycle events and things like AppDelegate functions, the sanity check may be more beneficial to have the log actually there.
Another temptation is to put log messages in Adapters if you are an Android dev. If you have a lot of data and information though, it’s easy for those messages to become mind numbing.
An additional thing I try to avoid is the overly scary log message or the log message that seems like it’s telling you something of importance but actually has little to no impact.
try { // Something } catch(Exception e){ // Recovery logic here Log.e(TAG, “Something tragic happened!”); }
If the app can continue or you can implement recovery logic, the log message is just a red-herring and something to just frighten the developers who haven’t become familiar with that section of code yet.
Another pet peeve of mine is the antithesis of chatty logs…it’s not logging information that could be vital. One example is when you are catching some kind of exception but not showing any indication that this has occurred. This gets compounded and adds to my stress level especially when there are multiple exceptions being caught.
Good Logging Practice
try{ // Do some things that could potentially cause an IO exception} catch(IOException e){ Log.e(TAG, “Exception occurred in ______ function”, e);}// Continue about the rest of the app
Bad Logging Practice
try { // Do some things that could potentially cause an IO exception} catch(IOException e) {}// Continue about the rest of the app
Really Bad Logging Practice
try { // Do some things that could potentially cause an IO exception} catch(IOException e) {} catch(ParseException e) {}// Continue about the rest of the app
I also encourage any developers to make use of log levels. If something is important or vital to know, then don’t toss it into the same bin as information or debugging information…crank it up to at least a warning! That being said, everything can’t be at the same importance level and remain easy to sift through, so just use your best judgment when deciding what to make stick out.
Logging is a great tool and stopping to think of the “What happened?” “Where did it happen?” “What else do I need to know?” and “How important is this?” really can improve your logging. There is nothing worse than a half baked log message that only tells you half the story.
Want to be apart of our development team?
