Live data from Hacker News

How Developers Choose Names

arxiv.org

21–30 of 157 posts

Re: How Developers Choose Names

#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)

Re: How Developers Choose Names

#22

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...

“Our JavaScript date library and the date library we’re using in Clojure disagree on the first day of the week. Elasticsearch disagrees with both too”

Re: How Developers Choose Names

#23

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...

You can avoid this problem by always passing in either a time or a time provider and never just relying on Time.now or whatever it is your language provides.

Re: How Developers Choose Names

#25

Earlier quoted context omitted.

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...

You can avoid this problem by always passing in either a time or a time provider and never just relying on Time.now or whatever it is your language provides.

This. Nearly every date/time library comes with this sort of attractive nuisance that is just waiting for a chance to ruin your day.

Re: How Developers Choose Names

#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.

Re: How Developers Choose Names

#27
post #4

One of the most cruel things evolution did to us is that we constantly seek meaning, order, correctness, where there are none to speak of.

I'd argue that the ability to unite people by assigning meaning onto things, places, and ideas is the single reason why humans have been so successful in advancing civilization to where it is today. Edit: eschew -> assign

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

Re: How Developers Choose Names

#28

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.

Re: How Developers Choose Names

#29

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...

Funnily enough, I recently had to help with an issue where a company's payment screen was not loading correctly and instead displaying "Invalid session". They use a third-party vendor to handle payments and display their payment form in an iFrame on their website.

There is an initial request to create a session that has to pass the desired expiration time of the session. Unfortunately, the vendor requires the time to be in Eastern Time. The poor, naive soul that originally implemented this just got the current date, added 15 minutes, and converted it to "EST". As soon as daylight savings hit a few weeks ago, the expiration time was automatically being set to 45 minutes in the past, the vendor was responding with "Invalid Session" and the company was unable to take payments from customers.

Re: How Developers Choose Names

#30

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’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.
Post reply on HN