Taming names in software development
simplethread.com
Taming names in software development
1–10 of 44 posts
Re: Taming names in software development
#2What this misses — and every other article I’ve seen about naming misses — is that the truly hard part of good naming is none is the stuff that was mentioned.
The hard part is this: taking the deserved level of care with naming often has to be done in a context with other humans who wrongly think that it’s simply not that big a deal, and their annoyance with having it brought up becomes an often unspoken source of friction. This not only leads to rancor but also has a chilling effect.
Even making the unspoken spoken often doesn’t help. The response will be like: oh yeah, choose some good names for us, knock yourself out, it’s great that somebody cares (but let’s not stop calling the timestamp a counter, or the database temmp_v3_old_Udpate_RstdnewV2, because reasons).
It can depend on the team, but in my experience successfully getting past these issues is usually way harder than any of the other factors mentioned.
Re: Taming names in software development
#3"In software, really good names are meaningful, descriptive, SHORT, consistent, and distinct." (emphasis mine)
I hate this general reccomendation style that names need to be short. This only made sense in the old times of programming where you had to actually type them. The reality of IDE's bringing all forms of intellisense and autocomplete means you almost never type a name out, thus being short brings no benefit if not "habit". You should really try to have understandable names, detailed names, but not care about shortness. "timeout" is a good variable name if you language has some great type system and your coding works with that. "timeoutInSeconds" is a better one if you are just using an int/long to distinguish it from "timeoutInMillis" and avoid silly mistakes.
Re: Taming names in software development
#4"In software, really good names are meaningful, descriptive, SHORT, consistent, and distinct." (emphasis mine) I hate this general reccomendation style that names need to be short. This only made sense in the old times of programming where you had to actually type them. The reality of IDE's bringing all forms of intellisense and autocomplete means you almost never type a name out, thus being short brings no benefit i…
> thus being short brings no benefit if not "habit".
IPersonallyFind tonsOfCode likeThisReally hardToParse, especially when the least important parts have the longest names.
As a result code like that can be overwhelming and sometimes make me dread working with it.
Re: Taming names in software development
#5What this misses — and every other article I’ve seen about naming misses — is that the truly hard part of good naming is none is the stuff that was mentioned. The hard part is this: taking the deserved level of care with naming often has to be done in a context with other humans who wrongly think that it’s simply not that big a deal, and their annoyance with having it brought up becomes an often unspoken source of fr…
This came up at my work Christmas party. One colleague on my team (1) hates my reviews because the naming things I point out are way too pedantic. Another colleague (2) in our same team loves my reviews because it makes them think about how it's read and understood.
It's difficult to convey why naming is important. (1) also feels that the code needs a lot more comments and berates others for not commenting their code. I have a hard time pointing out the irony to them.
Re: Taming names in software development
#6"In software, really good names are meaningful, descriptive, SHORT, consistent, and distinct." (emphasis mine) I hate this general reccomendation style that names need to be short. This only made sense in the old times of programming where you had to actually type them. The reality of IDE's bringing all forms of intellisense and autocomplete means you almost never type a name out, thus being short brings no benefit i…
> thus being short brings no benefit if not "habit". IPersonallyFind tonsOfCode likeThisReally hardToParse, especially when the least important parts have the longest names. As a result code like that can be overwhelming and sometimes make me dread working with it.
Yes, long names can be taxing too if taken to extremes. I use descriptive names that spell out the domain or business logic so code becomes as close to self documenting as it gets. However, locally when I have to reference these multiple times I use a short alias, usually the acronyms of the long names so it’s the best of both worlds: don’t have to carry around the long names everywhere but still have a fallback on them when I forget what they represent.
Re: Taming names in software development
#7"In software, really good names are meaningful, descriptive, SHORT, consistent, and distinct." (emphasis mine) I hate this general reccomendation style that names need to be short. This only made sense in the old times of programming where you had to actually type them. The reality of IDE's bringing all forms of intellisense and autocomplete means you almost never type a name out, thus being short brings no benefit i…
Long names should be a signal that you’re breaking away from current context or doing something unusual. Unnecessary length and redundant context makes names more difficult to discern. I wrote about it a bit more in the “what?” section of this post: https://max.engineer/maintainable-code
Re: Taming names in software development
#8What this misses — and every other article I’ve seen about naming misses — is that the truly hard part of good naming is none is the stuff that was mentioned. The hard part is this: taking the deserved level of care with naming often has to be done in a context with other humans who wrongly think that it’s simply not that big a deal, and their annoyance with having it brought up becomes an often unspoken source of fr…
> but let’s not stop calling ... the database temmp_v3_old_Udpate_RstdnewV2
I worked briefly on a codebase that was otherwise produced by Chinese programmers (in China).
It did feel somewhat surreal seeing variable names that were in English but misspelled, particularly when e.g. several classes all had a field of the same name, except that in one of them, the name was misspelled.
I assume it didn't bother them because (a) they weren't English speakers anyway, and (b) they autocompleted everything. Why would it matter that `update_history` happens to be spelled `udpate_history` in one out of five classes? You just type `u` and pick the right field.
Re: Taming names in software development
#9What this misses — and every other article I’ve seen about naming misses — is that the truly hard part of good naming is none is the stuff that was mentioned. The hard part is this: taking the deserved level of care with naming often has to be done in a context with other humans who wrongly think that it’s simply not that big a deal, and their annoyance with having it brought up becomes an often unspoken source of fr…
This came up at my work Christmas party. One colleague on my team (1) hates my reviews because the naming things I point out are way too pedantic. Another colleague (2) in our same team loves my reviews because it makes them think about how it's read and understood. It's difficult to convey why naming is important. (1) also feels that the code needs a lot more comments and berates others for not commenting their code…
And this is why code reviews while helpful can be wasteful. Reviews should be based on existing standards not preferred methods of each reviewer. Some people feel they need to comment so they over comment. Some feel they need to prove how much they know. Others may mark you down for doing it how the previous review recommended.
Re: Taming names in software development
#10"In software, really good names are meaningful, descriptive, SHORT, consistent, and distinct." (emphasis mine) I hate this general reccomendation style that names need to be short. This only made sense in the old times of programming where you had to actually type them. The reality of IDE's bringing all forms of intellisense and autocomplete means you almost never type a name out, thus being short brings no benefit i…
> thus being short brings no benefit if not "habit". IPersonallyFind tonsOfCode likeThisReally hardToParse, especially when the least important parts have the longest names. As a result code like that can be overwhelming and sometimes make me dread working with it.
do_you_prefer_underscores? iKindOfDo i_kind_of_do