Clean Code: Chapter 2 - Meaningful Names

Posted by Andy Huggins on January 22, 2016

So basically, it's better to give variables or classes more explicit names than to keep them short for the sake of brevity.

$activeAccounts is better than $a or $aAccounts. $activeAccounts gives other developers a heads up that this variable contains an array or list of active accounts.

Lower-case L and upper-case O should be avoided since they look like 1 or 0.

Recognize that there is a problem when you have something like $menuItems and $menuitems or $menusItems. Having to track down the difference between any of these three variables takes time and developers have to keep track of this in their heads. It would be better to standardize what the need for different variables is, and then fix the issues where the different variable names exist.

Don't use inside jokes or something cute as a variable name. Just keep it as clear as possible.

Use searchable names. I figured this one out before I read this chapter, but basically, when you use your editor, you will most likely have to search your project for a method, variable or something. Using a too short name like $user when it should be $activeUser. This would allow you to find activeUser in your editor. This is another reason that one word variables are annoying. $d might save some characters, but searching your project for d is going to return a lot. And yes, you could search for $d, but if you have a lot of these abbreviations, you will get a lot of results. It's better to name it something that separates it from other concepts. Exception to this would be $i as an iterator in a's traditional and usually going to be a locally scoped variable.