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

How Developers Choose Names

arxiv.org

Post reply on HN
Print view View original

51–60 of 157 posts

Re: How Developers Choose Names

#51

Post by katzgrau »

granshaw wrote: post #21

I have a rule called “name it what it does, not how it’s used” which is a mistake I often see with junior developers and sacrifices information density Eg it’s more helpful for readability to do “onClick => updateDate()” rather than “onClick => handleClick()” (Not the best example and I’ve seen far more egregious, but those examples are escaping me now)

Agreed, and something to add in the explanation of what to do is the "why."

When someone (or you) is reading the code later, you see a method call and know exactly what it does. This prevents you from having to click in or find it just to figure out what it does.

Frequently, if you click into a vaguely named method, it doesn't do the thing you were searching for and you wasted a little time and need to backtrack, only to repeat the cycle with other vaguely named methods.

Re: How Developers Choose Names

#52

Post by ape4 »

granshaw wrote: post #21

I have a rule called “name it what it does, not how it’s used” which is a mistake I often see with junior developers and sacrifices information density Eg it’s more helpful for readability to do “onClick => updateDate()” rather than “onClick => handleClick()” (Not the best example and I’ve seen far more egregious, but those examples are escaping me now)

But how its used is often inseparable from what it does. And in UI code its nice to have all user actions called OnXxx or some convention.

Re: How Developers Choose Names

#53

Post by ed25519FUUU »

How about numbering? I always use to get a sideways glance back in the day (before we all started using uuids) when starting the number for a server group at 0. You’ll only have 9 servers in the first group and 10 thereafter if you start at 1! Yet some people insisted.

Re: How Developers Choose Names

#56

Post by anon_tor_12345 »

dw-im-here wrote: post #54

Says in the paper they had 337 subjects, so we'll have to match them with 337 irrelevant anecdotes so that we too can be scientists

you think that's bad? this paper

http://pdinda.org/Papers/ipdps18.pdf

surveyed ~150 and concluded therefrom. the more hilarious thing being that they drew conclusion completely unscientifically i.e. by just interpreting vague plots (i.e. without performing t-tests or anything like that).

Re: How Developers Choose Names

#58

Post by city41 »

3grdlurker wrote: post #28
granshaw wrote: post #21

I have a rule called “name it what it does, not how it’s used” which is a mistake I often see with junior developers and sacrifices information density Eg it’s more helpful for readability to do “onClick => updateDate()” rather than “onClick => handleClick()” (Not the best example and I’ve seen far more egregious, but those examples are escaping me now)

I’m an engineering lead and I made a rule of using the handleClick() style instead of updateDate() in our codebase. The reasoning is that the latter sounds more like an atomic, standalone function, whereas handleClick() may have some internal checks that could eventually call something like updateDate(), but the internal checks are beyond the responsibility of the updateDate() function.

I agree. It's also nice to know when you see a `handle` function, it is getting slotted into an `on` somewhere. Within the handle I prefer to call functions such as updateDate().

But this whole thread brings up something about coding that has always irked me, it's very opinion based. When two people strongly hold the opposite opinions on the same team, it can be a massive hassle for absolutely zero benefit.

Re: How Developers Choose Names

#59

Post by dapids »

hanniabu wrote: post #43
3grdlurker wrote: post #28

Earlier quoted context omitted.

I’m an engineering lead and I made a rule of using the handleClick() style instead of updateDate() in our codebase. The reasoning is that the latter sounds more like an atomic, standalone function, whereas handleClick() may have some internal checks that could eventually call something like updateDate(), but the internal checks are beyond the responsibility of the updateDate() function.

Personally I would have both and within the handleClick() function do whatever it needs to do and call an atomic updateDate() function (assuming it's updating the date globally). Although for anything generalized standalone function I like to put that in its own namespace, such as helper.updateDate().

Or be explicit. Call it AtomicUpdateDate if such functionality is really desired. Nobody should assume any operation is atomic ... Unless it is explicitly stated to be so.

EDIT: sorry meant to reply to the parent comment.

Re: How Developers Choose Names

#60

Post by nuclearnice1 »

dw-im-here wrote: post #54

Says in the paper they had 337 subjects, so we'll have to match them with 337 irrelevant anecdotes so that we too can be scientists

“But choosing good meaningful names is hard. We perform a sequence of experiments in which a total of *334 subjects* are required to choose names in given programming scenarios.”
Post reply on HN