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

71–80 of 157 posts

Re: How Developers Choose Names

#71

Post by vas1 »

ttiurani wrote: post #64

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…

Couldn’t agree more with this. Consistency is key even if the convention used is awkward

Re: How Developers Choose Names

#72

Post by jawns »

ttiurani wrote: post #64

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…

This goes double for APIs, and triple for externally facing APIs, where typically the people who are working with it aren't familiar with your code base or naming conventions.

That's why good API design is so hard. Every name you assign to something becomes a convention by default.

Re: How Developers Choose Names

#73

Post by resonantjacket5 »

johnchristopher wrote: post #67

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…

getInstancesId() would usually mean a singular id corresponding to the group of instances.

Only ones with an "s" at the end of the id should return an array if you have the existing "getInstanceId" either that or invert that function to be getIdOfInstance and subsequently getAllIdsOfInstance for the array version.

Generally speaking don't use the possessive "s" it is implied by being next to it. Also I usually use "instance" in this case more like an adjective

Edit: usually I think of it as (current subject) verb adjective object.

So server get instance IDs becomes getInstanceIds() or zoo clean active dogs becomes cleanActiveDogs()

Re: How Developers Choose Names

#74

Post by echelon »

rileymat2 wrote: post #40
hallway_monitor wrote: post #33

Earlier quoted context omitted.

If you don't have refactoring that can rename functions across your code base, now you have two problems

In 16 years as a developer, I have never seen this beyond the scope of a single project/language. Once things cross boundaries it stops.

I've hit this many times.

Microservices and JSON APIs.

Common library code (eg. common session handling) incorporated into dozens of microservices.

Monorepos (which actually make this problem somewhat easier).

Re: How Developers Choose Names

#75

Post by username90 »

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)

That is all well and good, until you have many components all needing to handle clicks. Then it is better to do a handleClick abstraction and put the updateDate inside it.

Re: How Developers Choose Names

#76

Post by hinkley »

ttiurani wrote: post #64

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.

Re: How Developers Choose Names

#77

Post by bryanrasmussen »

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)

the benefit for handleClick in a react codebase at least is, aside from convention, generally there will only be one click action per component and then you can see right when you come into the component - hey there is a click somewhere in this component.

In that case what I find preferable is onClick => handleClick()

handleClick = () => { stuff in handle click updateDate(); }

on edit: I see lots of others made same point one node lower.

Re: How Developers Choose Names

#78

Post by hinkley »

city41 wrote: post #58
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.

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.

It also quickly explains to you that no, you can’t refactor this method to change the arguments.

Re: How Developers Choose Names

#79

Post by jariel »

hallway_monitor wrote: post #41
jariel wrote: post #26

This is one of the most interesting artifacts of programming, and it's probably impossible to explain to people outside the field. How at the same time it's trivial and important, and a constant cause of neuroticism. It takes up far too much tought-space to the point I would gladly follow some ugly set of conventions merely to have to just never think about it.

Sure, following some guidelines and standards is helpful. But never having to think about naming is almost like never having to think about logic. What you name things dictates how future developers think about them. Just this week we had a feature that could belong in an existing module or it could require a new module all depending on how we define the domain and therefore the name of the existing module.

"s almost like never having to think about logic. "

Not really, because naming is 98% convention when it's done right.

The challenge is establishing all the conventions for a project, and then sticking to them.

If there are really good conventions in place, well known, then naming is considerably easier.

In fact, even if the conventions are not super good - they can be powerful when they are very well adhered to.

Example: recently broke a rule and decided to use a known naming anti-pattern by suffixing variable names with the system type. This is normally not good. But within this module, the meta typing was ambiguous - by adding the suffix, the code was magically more clear. That little convention, very easy to apply, solved a clarity problem far more so than any issues around what functions should be called. So we used it for the module and that module only.

Apple has some pretty hardcore naming conventions that I don't really like, but what's more important then whether they are good or not, is that they are very consistently applied - in other words - a lot less to think about.

Post reply on HN