Live data from Hacker News

How Developers Choose Names

arxiv.org

81–90 of 157 posts

Re: How Developers Choose Names

#81

With naming what IMO matters more than choosing one name, is choosing a name that is consistent with other similar names in the codebase. A new developer will learn your project's specific convention in a few minutes, but will be completely lost if the convention is routinely violated here and there. This is especially important with what verbs to use in methods, and how to name interfaces/classes in a way that respe…

Yes, convention is more important that the quality of the convention. The convention abnegates the need to think about things, and for a developer, thoughts are precious.

Re: How Developers Choose Names

#82

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.

> may have some internal checks that could eventually call something like updateDate

This sounds like exactly the kind of pre-mature optimization that leads to overly-abstract function names throughout the codebase. Your point is a good one, once the function does something more than `updateDate()`. But until then, just call it `updateDate()`. As a bonus, this way any time you do choose to use `handleClick()`, the name is conspicuous enough that you pause to see what side effects it might have.

Re: How Developers Choose Names

#83
post #58

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.

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.

In training interns I had to figure out what part of my coding advice to them is best practice and what part is just the way I like to do things.

It's good to know the difference and it gave them the space to challenge me on some of those methods, which in turn helped me write better code.

Re: How Developers Choose Names

#84
post #76

With naming what IMO matters more than choosing one name, is choosing a name that is consistent with other similar names in the codebase. A new developer will learn your project's specific convention in a few minutes, but will be completely lost if the convention is routinely violated here and there. This is especially important with what verbs to use in methods, and how to name interfaces/classes in a way that respe…

You have to be careful with your definitions. Don’t use different definitions of the same verb/noun in different places. You get one. If you need another definition elsewhere, use a synonym. It is not beneath you to hit thesaurus.com while picking a name.

A thesaurus is one of my favorite dev tools.

Re: How Developers Choose Names

#85
post #27

Earlier quoted context omitted.

That's precisely the problem. It's very useful, when it's useful. Which leaves us spinning in circles when it's not.

It would be impossible for you to say this (circular) sentence and call something a “problem” if you didn’t think that there was some basis of right/wrong, which contradicts your top-level comment.

See, this shouldn't cause a deep sorrowful void within me, but it does.

Re: How Developers Choose Names

#86
post #36

Earlier quoted context omitted.

I’d agree in some cases, but then you get weird debouncing code in your update date function. Because, no one wanted to change the onClick function name in 38 different places when it starts to do more.

onClick => onAccept => submitRequest The downside is lots of little functions, the plus side is smaller behaviors. (Ie avoiding 5 levels of nesting in a single function.)

This sort of thinking leads to codebases that are too abstract, where it’s hard to follow the flow of execution.

There’s nothing wrong with 5 levels of nesting. It’s much easier to follow than 5 separate functions.

Re: How Developers Choose Names

#87

As a non native english speaker I have a recurring problem with this: > getInstances(); // ok, returns an array of instances > getInstanceId(); // ok, returns an id > getInstancesId(); // ??, returns an array of id > get InstancesIds(); // ?? returns an array of id > getIdsOfInstances(); // ?? returns an array of id > getAllInstancesId(); // ?? returns an array of id > getAllInstancesIds(); // ?? returns an array of…

As a native English speaker (and former English teacher), hope this helps:

> getInstances(); // ok, returns an array of instances

Correct.

> getInstanceId(); // ok, returns an id

Correct.

> getInstancesId(); // ??, returns an array of id

Unusual, but would return a single ID referring to a collection of instances.

> get InstancesIds(); // ?? returns an array of id

Correct.

Though more common would be getInstanceIds() since you don't need to pluralize twice. E.g. we don't say "blues shoes", we say "blue shoes", so these aren't "instances ID's" but "instance ID's".

However, in naming functions or variables you'll sometimes see plurals repeated for clarity. E.g. getInstanceIds() is ambiguous because it could refer to the ID's of multiple instances, or multiple ID's of the same instance. While getInstancesIds() makes it clearer that it's the ID's of multiple instances, even though it's not actually grammatically correct.

> getIdsOfInstances(); // ?? returns an array of id

Same as getInstanceIds(). Both are correct, though getInstanceIds() would probably be more common -- most people wouldn't put in the extra word "of" simply because it's an extra word, but sometimes it might be clearer for consistency with other function names.

> getAllInstancesId(); // ?? returns an array of id

It would mean the ID for the collection of all instances, though that would seem very unusual. Perhaps if there were a global account ID for a service or API you used.

> getAllInstancesIds(); // ?? returns an array of id

Sams as getInstanceIds(), but "All" presumably means it doesn't include a parameter to filter -- so I'd assume this implied the existence of another function such as getCollectionInstanceIds() or similar that it was contrasted against.

> How do I conjugate that ? And what about the possessive `s`?

Obviously you can't or shouldn't use apostrophes in variable names, so people generally try to avoid the possessive s. That's why we generally change nouns to noun adjectives -- instead of "computer's ID" (computer = noun) we use "computer ID" (computer = noun adjective).

Re: How Developers Choose Names

#88

Naming things - one of the four hardest problems in computing (the others are sorting and off-by-one errors) :)

Don't forget time comparison. Your unit test of a function comparing dates relies on server time and usually fails if run around 12pm. Whatever. Nobody uses this app around lunch time anyway. Just tell your teammates in the to ignore that. Wait, why is the test failing every time today?! Did we just switch to DST? Uh oh...

I recently came across a 15 year old bug in qt involving both time comparison _and_ cache invalidation: the code was trying to set timers to fire when the next cache entry was set to expire, but the timeout was in seconds while the eviction code compared milliseconds. The result was 100% cpu usage for up to a second as the timer spun without evicting the cache entry.

Re: How Developers Choose Names

#89

Naming things - one of the four hardest problems in computing (the others are sorting and off-by-one errors) :)

Don't forget time comparison. Your unit test of a function comparing dates relies on server time and usually fails if run around 12pm. Whatever. Nobody uses this app around lunch time anyway. Just tell your teammates in the to ignore that. Wait, why is the test failing every time today?! Did we just switch to DST? Uh oh...

Funny related story: For an internship, I worked on a app that would show your sleep data in a nice visualization (this was for a smartwatch). I implemented a basic version, and used it for a few weeks. It seemed to work fine for me, so I released a beta version for others in the company to dog food.

Within a day, I got a bug report from a coworker that it rendered incorrectly for them. I was pretty surprised, since I had been using it for a long enough that I would have expected to encounter all the edge cases.

I dug into the code, and realized that this bug only happened if you went to sleep before midnight, which I never did...

Re: How Developers Choose Names

#90

With naming what IMO matters more than choosing one name, is choosing a name that is consistent with other similar names in the codebase. A new developer will learn your project's specific convention in a few minutes, but will be completely lost if the convention is routinely violated here and there. This is especially important with what verbs to use in methods, and how to name interfaces/classes in a way that respe…

Naming gets far worse than that. I've worked on code where the naming was not just unhelpful, it was outright misleading. One of the worst I remember was a project which unsurprisingly was named after a game of thrones character. As I never watched game of thrones it took me about two weeks before I could even remember the stupid name, during which time I was also dumbfounded as to how the program worked until I realised the naming in the code was equally bad, completely misleading. Then there's the place where the stg1 environment was actually the dev0 environment...
Post reply on HN