Names shouldn’t spread disinformation.
As in above pasta example or the variable ‘cache_2008_temp’, there is a certain amount of disinformation being spread. If the variable was named ‘a’ and the bottle didn’t have any label, they wouldn’t tempt anyone to make assumptions. Variables which spread disinformation are dangerous because there is a chance that their intention might be deciphered wrongly.
I have picked the following code snippet from a previous post of mine :
1: //code snippet 1
2: static void Main(string[] args)
3: { 4: var now = DateTime.Now;5: var nyTimeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");
6: var nyNow = TimeZoneInfo.ConvertTime(now, nyTimeZoneInfo); 7: var nyTodays17Hours = nyNow.Date.AddHours(17); 8: var nyNext17Hours = nyNow < nyTodays17Hours ? nyTodays17Hours : nyTodays17Hours.AddDays(1); 9: var localTimeWhenNyNext17HoursOccurs = TimeZoneInfo.ConvertTime(nyNext17Hours, nyTimeZoneInfo, TimeZoneInfo.Local); 10: 11: Console.WriteLine("localTimeWhenNyNext17HoursOccurs is " + localTimeWhenNyNext17HoursOccurs);
12: 13: Console.ReadKey(); 14: }localTimeWhenNyNext17HoursOccurs allow you to breeze through the code when you read it. Now let me rewrite the code using bad variable names.
1: //code snippet 2
2: static void Main(string[] args)
3: { 4: var now = DateTime.Now;5: var nyTimeZoneInfo = TimeZoneInfo.FindSystemTimeZoneById("Eastern Standard Time");
6: var ny1 = TimeZoneInfo.ConvertTime(now, nyTimeZoneInfo); 7: var ny2 = ny1.Date.AddHours(17); 8: var ny3 = ny1 < ny2 ? ny2 : ny2.AddDays(1); 9: var ny4 = TimeZoneInfo.ConvertTime(ny3, nyTimeZoneInfo, TimeZoneInfo.Local); 10: 11: Console.WriteLine("localTimeWhenNyNext17HoursOccurs is " + ny4);
12: 13: Console.ReadKey(); 14: }Variable names shouldn’t require a comment to understand them.
1: //code snippet 3
2: List<int> cache_2008_temp //history of records in 2008;
In code snippet 3, we see that the variable ‘cache_2008_temp’ has been commented to tell us that it is used to store history or records in 2008. But, what happens to the code where it is used? Anyone who reads the code using that variable is bound to get confused. It destroys the readability of the code because that name makes no sense – it spoils the code story. So, after sometime a developer who maintains that piece of code thinks that no longer is the 2008 history necessary then she might just rename the variable as ‘cache_2009_temp’ and use it to store history of 2009 records. But she might forget to update the comment. As code evolves comments get outdated and hence reliability on comments to understand the code can be dangerous.
So instead of naming the variable in snippet 3 ‘cache_2008_temp’ we could have named it ‘historicRecordsOf2008’ or just ‘recordsIn2008’. Names should convey the intent correctly. Such names bring a clarity to the code. Code cannot achieve simplicity if there isn’t any implicit understanding of names.
A variable name like ‘cache_2008_temp’ is difficult to pronounce and use in discussions. Instead ‘historicRecordsOf2008’ can be easily be used while discussing the code. Use names which you can pronounce and hence can easily use while discussing the code.
To have good names you need to think, think hard. And that takes time. But as Uncle Bob says choosing good names is hard and takes time but saves more time than it takes in future.