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

41–50 of 157 posts

Re: How Developers Choose Names

#41

Post by hallway_monitor »

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.

Re: How Developers Choose Names

#42

Post by [deleted] »

granshaw wrote: post #35
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.

Yes my example was if updateDate literally just updates the date - I take this a step further too, Eg if the function has some extra checks, I’ll name it maybeDoX(), which is a somewhat uncommon practice in common programming languages

[deleted]

Re: How Developers Choose Names

#43

Post by hanniabu »

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.

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

Re: How Developers Choose Names

#44

Post by jbluepolarbear »

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 take this approach as well; especially, when the handle takes an event param and can then let the object react with the correct behaviour.

Re: How Developers Choose Names

#45

Post by dividedbyzero »

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.

Even within those bounds, I found it doesn't always work terribly well (depending on the language, tooling and project complexity)

Re: How Developers Choose Names

#46

Post by anonu »

I find that I am remarkably internally consistent with how I name things. I sometimes forget about a filename, class or function that I wrote months ago (thats another problem in itself). But when I go to name the new thing I am about to write I realize that it already exists. I then pat myself on the back.

Re: How Developers Choose Names

#48

Post by loloquwowndueo »

karmakaze wrote: post #13
loloquwowndueo wrote: post #2

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

Sorting actually isn't one, at least anymore. Exact once and in-order delivery although part of 'distributed' computing should be, since most computing is distributed, right down to our multicore processing hardware.

It is - do your sorting, then show the results to stakeholders and you’ll see they all want different, mutually conflicting sort orders.

Re: How Developers Choose Names

#49

Post by coliveira »

slver wrote: 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.

Well, with the internet we don't need to do it anymore. Everyone has lost the battle to organize the internet, and it is now the helm of run away AI algorithms. And the same is happening to other areas which are controlled by AI and "big data".

Re: How Developers Choose Names

#50

Post by baby_wipe »

My process:

(1) How would I explain face-to-face what this code does to another developer?

(2) Use the key words from that explanation to make a name as short as possible without losing clarity.

Example:

Step 1: This class handles all the navigation work for the sign-up flow in our mobile app.

Step 2: SignUpFlowNavigator

Post reply on HN