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

111–120 of 157 posts

Re: How Developers Choose Names

#111

Post by samatman »

crazygringo wrote: post #97
pcthrowaway wrote: post #95

Earlier quoted context omitted.

Interesting. I've seen the apostrophe for acronyms which involve periods: e.g. "C.D.'s" (NYT has an article about this being their preferred style) I've seen it for one-letter words where you don't want to switch case: e.g. "dot your i's and cross your t's" But I haven't seen it in upper-cased abbreviations followed by a lower case plural 's'. Or if I have, I've assumed it's wrong. Would love it if you can refer me t…

I just added a link to a Wikipedia discussion in my comment above, which should answer your question. It gives an example: > ...whereas The New York Times Manual of Style and Usage requires an apostrophe when pluralizing all abbreviations regardless of periods (preferring "PC's, TV's and VCR's").

I would make a case that in our field, one which has an abundance of initialisms and non-period-separated acronyms, we shouldn't shadow the possessive. Consider "this script retrieves JSONs from all API URLs and validates them against their respective schemas" and "this function extracts the URL's fragment, if any, and checks it against a set of page targets". If you use an apostrophetic plural, does the latter receive one URL, or a collection of them?

URL was carefully chosen, since you can't make a consistent ruling about initialism vs. acronym, I've worked with people who pronounce it "you are ell" and people who say "earl", and sometimes both! Absolutely no one is going to start spelling it U.R.L., either.

Especially given the abundance of non-native speakers, let's not add a peculiar and ambiguous edge case to one of the more frustrating rules of English grammar.

Re: How Developers Choose Names

#113

Post by bitwarrior »

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)

It entirely depends on what the function is receiving.

In your example, assuming we're looking at a React codebase (since this seems to square with React's style of events, etc), the resulting data being set into the updateDate function would be an event.

This, unfortunately, doesn't make any sense for a function by the name of updateDate to receive. I would expect to receive at least a new date to update with in the parameters, or ideally in a functional world, both the state to update and the new date we want applied to it. Anyone thinking they could simply reuse the updateDate function somewhere else is going to be woefully disappointed they largely cannot, since it would have been constructed around receiving an Event object.

In that case, I find the "handle" nomenclature to be very useful, as it appears to be largely shorthand for functions design to handle an _event_ (and we tend to see this pattern being used in various React libraries and documentation). React does have a few of these shorthands it tends to use (such as useEffect largely being short for useSideEffect).

Ultimately, I recommend using both functions. One, a handleClickUpdateDate function (notably not a hyper-generic handleClick function which conveys nothing) that receives the event and pulls out the necessary information out of that event to determine what the date is that the user has selected. It then will call the updateDate function with only that date, which creates a nice, reusable updateDate function if we need it anywhere else.

This roughly squares with the idea of having functions that handle the data transport layer (such as receiving data via HTTP or gRPC, etc) whose responsibility it is to receive those events, pull out the necessary information out of the package, route the request to the correct controller, and ultimately return the result in a shape that satisfies the original transport mechanism. In this case, our handle* function is responsible for receiving the original transport of data, then routes the request through to the appropriate controller which is entirely unaware of the means of data transport.

It also means we have a nice, easily testable unit of updateDate to verify our state modification is working to our liking without needing to assemble an entire Event object.

Anyhow, that's how I think of these things ;p

Re: How Developers Choose Names

#114

Post by aYsY4dDQ2NrcNzA »

scubbo wrote: post #100
archsurface wrote: post #90

Earlier quoted context omitted.

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

> Then there's the place where the stg1 environment was actually the dev0 environment... Hey, think yourself lucky. It's only a pretty recent occurrence that my team has more than just the two "Prod" and "Non-Prod" environments...

Using the name “prod” for anything other than delivering code to external customers is one of my eternal pet peeves.

Re: How Developers Choose Names

#115

Post by PicassoCTs »

jariel wrote: post #81
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…

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.

With a good convention, even more important, structure can be derived and deduced, without reading the documentation. I love it, when i begin to grasp the structure of a codebase, write a line and hit auto-complete and the codebase was reliable. Functionname exists and parameters expected are served up. The code just feels so much more discover-able in such moments.

Re: How Developers Choose Names

#116

Post by rickbad68 »

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)

This example is not good for talking about naming as there is no proper design which would have a function like this. In any proper design there would always be a separate function for each of the concerns.

Re: How Developers Choose Names

#117

Post by dexwiz »

irrational wrote: post #70
dexwiz wrote: post #66

Earlier quoted context omitted.

I completely disagree with this example. Only in first order implementations does that click just change the date. As you refine UX you may add some debounce, error handling, alternative behavior, etc. DOM events rarely end up corresponding to such simply expressed handlers. Also when you are reading the reverse, it’s not clear on what on what updates date. The worst scenario is when two listeners share a handler.

What are your naming recommendations?

Exactly what OP discourages. Ha dleClick for onClick, handleDragOver for onDragOver, etc.

Re: How Developers Choose Names

#118

Post by rickbad68 »

This seems such a weird study. Names are important, but not so much as what is being named. In one sense, names become easy given a properly abstracted design. Further, it’s not names so much that are paramount to program comprehension, but more the quality of the design. With a bad design that doesn’t properly separate concerns it won’t be possible to come up with good names because functions/data structures will represent multiple concerns. Any time names are controversial it probably indicates a design problem, even for unique/complex abstractions, there is usually a name which everyone agrees is the perfect name for a thing..

Re: How Developers Choose Names

#119

Post by crazygringo »

samatman wrote: post #111
crazygringo wrote: post #97

Earlier quoted context omitted.

I just added a link to a Wikipedia discussion in my comment above, which should answer your question. It gives an example: > ...whereas The New York Times Manual of Style and Usage requires an apostrophe when pluralizing all abbreviations regardless of periods (preferring "PC's, TV's and VCR's").

I would make a case that in our field , one which has an abundance of initialisms and non-period-separated acronyms, we shouldn't shadow the possessive. Consider "this script retrieves JSONs from all API URLs and validates them against their respective schemas" and "this function extracts the URL's fragment, if any, and checks it against a set of page targets". If you use an apostrophetic plural, does the latter rece…

I'm intrigued, but I'll admit entirely confused, by your comment.

First, I don't know what it means to "shadow" the possessive. Do you mean we shouldn't hide it? Although it always has an apostrophe so we're never hiding it.

Second, I don't understand your examples. Your second example clearly necessarily uses the possessive, while the first is a plural, but the first would clearly be plural even with an apostrophe:

> "this script retrieves JSON's from all API URL's"

And since a possessive necessarily precedes another noun in this type of construction, it would still be clear:

> "this script retrieves JSON's from all of the API's URL's"

It's clear in speech and clear as written, even though the "'s" serves two grammatical purposes here.

Re: How Developers Choose Names

#120

Post by throwawayboise »

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.

validateAndUpdateDate()
Post reply on HN