Programming on AutopilotWritten by Chris Rowe on 14 May 2016 Tweet
One of the simplest and most useful feature of modern IDEs is in their support for automated refactoring, code generation, and generally taking away some of the more mundane tasks from the developer. Let's face it, who wants to go back to sorting out your own Java imports at the top of a class file?
Useful as these features are, there are downsides to relying on having the environment do too much for you. On a couple of recent projects I've seen it lead to a some bad habits - the impact of which have varied from the possibly-annoying to the actually-dangerous.
By way of an example, on a recent project, it was common practice amongst a number of the developers to always override the
toString() methods of DTO-type classes, incorporating all members. Both IntelliJ IDEA and Eclipse will happily produce this code for you if you ask.
toString() in particular made observing the current state of an object simple, either in the console or debugger. The natural extension to this was to use it for logging too -
log.debug(domainObject) and you've written a full snapshot of the state of the object to the log in a single statement. So far, so easy.
However, not all of our domain types were simple with a handful of members. There were a number that were far more complex, either by number of members, or by the fact that they held references to other DTOs (with their own
toString() implementations that would also be called). It does not take long for your single line of code to produce dozens of lines in the log file. The majority of which may not even necessarily relevant to the reason you're writing a log statement in the first place.
I see this kind of practice as being an extension of the that's the way we've always done it attitude - basically a process that has become so much of a habit, that no consideration of why it's done is generally given. I took to calling such behaviour 'Autopilot Programming' - people were willing to continue with doing things the same way and not really thinking about the consequences.
Now, of course, having busy log files because you've auto-generated
toString() the whole time isn't the end of the world. Yeah, the SNR sucked, but disk is cheap and analysis tools are getting better and better. But what happens when one of the members of your DTO contains something sensitive? Like a private key, for example? Yeah, that happened - was written out every time we wanted to log anything to do with one of those objects. Which was a lot. Because a developer didn't think about what they were doing and just carried on on autopilot...
About the Author: Chris is an experienced Software Developer, having been cutting code for organisations large and small since graduating in 2000. He currently specialises in building simple, secure, and elegant Java-based backend services. An Agile enthusiast and Certified Scrum Master, you can find his professional profile at LinkedIn. Away from work you'll probably find him playing football, training for various obstacle course and endurance events, or with his feet up having injured himself doing one.