Pretty long article with little substance. I have swung back on forth on variable naming over the years. Right now for me the focus is on part V of this articl

Pretty long article with little substance. I have swung back on forth on variable naming over the years. Right now for me the focus is on part V of this article. Currently I prefer shorter variable names, even if they require a bit more context. Let's use a concrete example. Say I'm writing a lambda function, and I name it LambdaThatDoesTheThing. This is a long name that (suppose) clearly describes the Lambda. This requires little context, tells me what the function does, and it helps me to tell it apart from others. So far so good. Now imagine we want to add Metrics, so we call them LambdaThatDoesTheThingMetrics. But maybe we have different kind of metrics, so we actually need two objects, LambdaThatDoesTheThingExecutionMetrics, and LambdaThatDoesTheThingFailureMetrics. We also want alarms, so we add LambdaThatDoesTheThingAlarms. And we want a dashboard, so we add LambdaThatDoesTheThingDashboard. These variables by themselves might not be a big deal, but when you compose them together they create big chunks of code. At some point the long names actually obscure the intent of the code. What if instead we encapsulate all of this in a function createLambdaThatDoesTheThing, and then remove the long prefix from all variables? Now we can clearly see that we are manipulating Metrics, Alarms and Dashboards. Sure, we need a bit more of context, but once we have that, the code is much easier to read and follow. This infrastructure example might be a bit synthetic but I believe it represents how some real codebases are written.