The second episode of Clean Coders covers some key rules to keep in mind when naming your variables, classes and methods. I’ve read parts of the Clean Code book before so much of this was review, but it was a much-needed review. The video breaks down each rule into a section with a tidy, animated title sequence— but it was actually two comments made without fanfare that were the big takeaways for me.

1) “The true cost of software is in maintenance”

I’m sure that I’ve read or heard this statement before, but maybe because I’ve been working with the same tic-tac-toe code for two-and-a-half months now that it really sunk in this time. There have been many times that I’ve wanted to scrap all of the code I’ve written and start from scratch, but working with and cleaning up my original code has been a valuable lesson, and little by little I’ve managed to get it to a relatively maintainable state. Leaving code cleaner than you found it is also a key component of the 8th Light philosophy so it’s been good for me to practice that on my own code.

I can also now start to see an even clearer picture of why clean code that is test driven, adheres to SOLID principles and uses established design patterns will ultimately save a customer or company that much more money— both in the long run and in the short run.

A huge amount of time and effort can be lost if a developer needs to figure out and/or rewrite poorly written code every time they want to make an upgrade or add a feature. Developers should hope that the project their working on is successful enough to be passed on to others, so it’s important that anyone should be able to jump in on a section of the codebase and not feel like they’re completely lost.

Even when a solo developer is “cranking”, code they wrote just a few weeks ago could feel like a distant memory, but if they’ve approached their code with a disciplined practice then it will be that much easier for them to go back and tweak something or add a feature.

2) “Names are not just for our convenience, they are the tools we use to communicate”

My second takeaway from the episode ties all of this savings in time and money back to the specifics of naming and how it leads to better code. As I discussed in some of my earlier posts and as one of the main points of both McBreen’s and Beck’s books- developing good software is about people more than anything else. It’s about having a steady and clear line of communication between developers, customers and users—and it’s much easier for those people to talk about code that has clearly named variables, classes and functions. The episode covers several specific guidelines for good naming techniques, but I wouldn’t want to spoil it for you. I definitely recommend checking out the book or the video.