Welcome to Part 3 of this review of the Pluralsight course Clean Code: Writing Code for Humans by Cory House.
Cory is a Microsoft MVP in C#, founder of OutlierDeveloper.com, avid tech reader, and speaker. He believes in clean code, pragmatic development, and responsive native UIs.
Here are the links to each part in this series:
Part 1 – Writing Code For Humans
Part 2 – Clean Code Principles
Part 4 – Clean Code Conditionals
In this episode we explore the importance of, and ways to achieve, good naming.
This is an example of dirty code due to bad naming, and then see the clean version.
The only change is an improvement to the naming, but the difference in readability is striking.
This shows a number of examples of bad class names.
I almost laugh out loud, because I have seen almost every one is these bad class names over the years, and you will likely have seen them as well.
Cory provides several guidelines for good class names. We see the first specific reference to one of the SOLID principles here.
Method names should be specific and give the reader a good understanding of what the method does without needing to read all of the program logic within it.
Cory lists many examples of bad names, and some much better ones.
You might wonder whether Cory has completely lost his mind as he recommends putting a rubber duck on your desk so that your explain your code to it.
There are however real benefits in doing this! In my office, there is no rubber duck, but there is a toy frog.
His name is Reginald. Reginald the frog. As well as being interested in all of our coding problems, he serves as a reminder to us to do our stand ups.
Words like And, Or, If in your method names suggest that your method is attempting to do more than one thing.
Some examples of method names and what they should not do as well.
Hey remember the 80s? What’s up rat fans! Turtle power! I have the power! All those TV shows. Ah, memories!
Boolean names should sound like they are asking a true/false question, and we some examples of those that do and don’t here.
Names for opposites should be opposites. Cory discusses some of the almost opposites, and contrasts them with the clarity of good symmetrical naming.