It’s been about a year since I read Robert Martin’s book, Clean Code: A Handbook of Agile Software Craftsmanship, and I figure it’s time I revisit the principles that still stand in this 15 year old book. I took a look at this short article by Tyler Hawkins which gives a quick rebuttal to those who say Uncle Rob’s book is out of date, followed by a quick list of all the advice given by chapter. In this blog post i’ll take two pieces of advice from Clean Code to talk about: one that I want to do more, and one thing I currently do the opposite of and want to avoid.

One thing I want to start doing more of is having meaningful names. Early on in Clean Code, Uncle Rob mentions that code is read far more often than it is written. This is so important that a whole chapter of the book is dedicated to it. The thing from this chapter I want to particularly work better on is making searchable names for things. I frequently name things based on what is immediately obvious instead of thinking of a name that fits the actual description. This usually manifests in me naming a field in a table, a function, or a some class something arbitrary. Then a month later, i’m unable to search for it because I can’t remember what it was named. Here’s an example I had to deal with recently. I was searching for a field I had made that held the date of when an item was priced. This ended up being the field I was looking for:

item.incentives_ran

Why did I call it incentives, this isn’t a field in the database? Why did I say they had ran? Does this field store a boolean or a date? Who knows what I was thinking when I had named this; I certainly wasn’t thinking about if the name would make sense to me a month later.

I think keeping in mind that i’ll want to be able to find something a month from now will lead to better naming, as i’ll be more aware of how whatever i’m naming will look to others and myself in the future.

One thing I need to STOP doing is making functions that do way too much. To that effect, chapter 3 of Clean Code shares the advice of making functions do one thing. A unfortunately frequent find in my code is a convoluted method that tries to do it all. It will make two different API calls, and return many different possible values. I often end up breaking this function up because I’ll find the need to use parts of it somewhere else (which is a whole other conversation on its own). Making functions that only do one thing will reduce the complexity of my code both logically, but also in terms of readability. It will also keep them from sprawling across entire files, which Uncle Rob isn’t terribly fond of:

“The first rule of functions is that they should be small. The second rule of functions is that they should be smaller than that”

Robert Martin

Using better names and making functions that do only one thing will probably mow down some seriously un-clean code in my work. While Uncle Rob’s book is older than a handful of commonly used programming languages, many principles evidently still apply.