Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Taming names in software development

simplethread.com

Post reply on HN
Print view View original

11–20 of 44 posts

Re: Taming names in software development

#11

Post by durandal1 »

drekipus wrote: post #5
natch wrote: post #2

What 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…

One thing that I've found over and over again, is that if something is hard to name, there is often a problem with the abstraction itself. Most common issue is that the thing that resists naming is doing multiple things and that it should be split up in smaller parts that focuses on something small that can be simply named.

Re: Taming names in software development

#12

Post by js8 »

Personally, I found there are two important aspects of things being named that are hard to express in names:

1. How important the thing is when it comes to big picture. Is this function where the meat of the program is, or it's just a technicality? Is this the main data structure or just something temporary? Good names should tell me what to focus on when reading the code.

2. Whether the name describes only the thing as it is, or actually prescribes what its use is. For example, LinkedList is descriptive because it tells only that the thing is a data structure, but it's up to you how to use it. On the other hand, CustomerRecord is prescriptive - it might be just a bunch of strings, but it also tells me what the intended use is, which is not necessarily contained in the code itself - it might be just some boilerplate to manage it in the database.

Re: Taming names in software development

#13

Post by Falkon1313 »

ParetoOptimal wrote: post #4
TheFattestNinja wrote: post #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 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.

I find they also often indicate over-abstraction or over-complicated generic stuff that is often kind of irrelevant to the domain.

Equipment_Maintenance_Criteria isn't super short, but it appears to actually mean something. Definitely tells you more than just "Selection" would. But all too often it's called something like AbstractServiceFactoryBuilderManagerLocatorPlugin which really doesn't tell you anything at all and leaves you at the end knowing less than you did when you started reading it.

Re: Taming names in software development

#14

Post by blowski »

TheFattestNinja wrote: post #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 i…

Perhaps "short" is a shorter way of saying "quick to parse". Even with IDEs, I still want that, lest I end up having to choose between names like this all the time:

- MinimumPriceCalculatorFactory

- MinimumPriceCalculatedPriceFactory

The extra couple of seconds every time becomes distracting and irritating.

Re: Taming names in software development

#15

Post by dmurray »

thaumasiotes wrote: post #8
natch wrote: post #2

What 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 becau…

I've seen the same thing many times with English-speaking programmers. Plenty of people just don't spot that 'udpate_history' is misspelt.

Re: Taming names in software development

#16

Post by wging »

TheFattestNinja wrote: post #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 i…

I disagree. The utility of short names is not just that it takes less effort to write them. They're also far easier to read and understand. IDE autocompletion doesn't help with that, nor does any other tooling, really. Since code is read much more frequently than it's written (including but not limited to any time that related code has to be changed), names should be as short as possible without sacrificing clarity. Excessively long names are harder to parse, and can slow you way down when trying to understand code.

(I'm arguing against what I see as your central point, but to be fair, 'without sacrificing clarity' is doing a bit of work in the paragraph above... your example is actually a good case of a bit of additional length being actually worth it. I would say timeoutMs or timeoutSecs are good shorter alternatives, "ms" and "secs" being widespread and clear abbreviations. You're completely right that 'timeout' is insufficiently clear for a purely numeric type, though I'd disagree that you need all that much type system magic to make it OK. For example calling a `java.time.Duration` `timeout` seems fine.)

Re: Taming names in software development

#17

Post by beeforpork »

How locally a variable is used should matter for selection of a name, too. I don't find i, j, k, o, p, k, v at all offensive if their scope is just a few lines of code. Usage is often idiomatic (e.g., k, v for iterating a map or i for an integer loop variable) and using a longer name would just make it less idiomatic and less obvious.

Re: Taming names in software development

#18

Post by teddyh »

ipaddr wrote: post #10
ParetoOptimal wrote: post #4

Earlier quoted context omitted.

> 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

In Emacs: M-x glasses-mode

Re: Taming names in software development

#19

Post by jffhn »

TheFattestNinja wrote: post #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 i…

In small methods I tend to use shorter names, even very short non-descriptive names, because there is less context so less chance of confusion, and it makes it easier to see what's going on in a glimpse (and check it matches method name).

On the other hand, if some public method does multiple things that need to be known to decide where it can be called, I put them all in its name.

Re: Taming names in software development

#20

Post by eilgin »

ipaddr wrote: post #9
drekipus wrote: post #5

Earlier quoted context omitted.

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.

i found that even with existing standards, some people use to adapt the meaning to their own ends because either what they think are ALWAYS right or they really just don't care.
Post reply on HN