How Developers Choose Names • Hacker News Board

Re: How Developers Choose Names

#151

Post by username90 » Mon, Apr 19, 2021, 10:47 AM UTC

krupan wrote: post #129

amelius wrote: post #99

Say what you want, but it's better than how mathematicians choose names imho.

The single letters are pretty bad, but when we use a persons name instead of a concept to describe something is where it gets truly awful. What the heck is an Eigen vector? Gaussian curve? Cartesian coordinates? Hilbert space? Julia set? Mersenne prime? Zero chance of intuiting any of that

Math needs way more names than English can support and since they are used by humans they lack namespaces. Human names are both easy for humans to speak and plentiful enough to satisfy the need for names in math, I don't see a better solution.

Re: How Developers Choose Names

#152

Post by dTal » Mon, Apr 19, 2021, 12:42 PM UTC

calvinmorrison wrote: post #138

whatshisface wrote: post #124

Earlier quoted context omitted.

A good name has maximal information density. If the string is compressible, you're wasting your reader's time. That's why I use all utf-8 glyphs to render my uniformly random and highly informative (from an information theory standpoint) variable names.

I do see this more often in UTF8 native platforms. arr1 and arr2 might use subscripts for 1 and 2 with no side effect on plan9. Why use "delta" when writing a delta symbol is so easy?

Julia not only supports Unicode, but embraces it culturally. You indeed very often see Δ in Julia code.

Re: How Developers Choose Names

#153

Post by joekrill » Mon, Apr 19, 2021, 12:52 PM UTC

hinkley wrote: post #76

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.

100%. I use RhymeZone and Wordnik more than I care to admit during development work.

Re: How Developers Choose Names

#154

Post by Asraelite » Mon, Apr 19, 2021, 3:42 PM UTC

patrick451 wrote: post #134

uyt wrote: post #127

Earlier quoted context omitted.

In defense of mathematicians, having conventional single letter variable makes stuff a lot easier to read. For example in graph algorithms, I used to write descriptive names like: weight = adjacenyMatrix[node][neighbor] Nowadays I write it as: w = G[u][v] Because in graph theory, an edge is usually (u, v), weight is usually w, graph is usually G, etc. It's basically the same reason why people don't name their indices…

When writing code that is mathematical, I firmly believe "descriptive" names are an anti-pattern. To figure out what anything complex is doing, I'm going to have write the equations on paper anyway, and a matrix called G instead of adjecencyMatrix speeds that process along greatly. Even better, if the variable names are sufficient short and mathy, I may not need to translate back to paper, since the equations become…

In maths, you usually write "where x is ..., y is ... etc." after equations where what the symbols represent isn't abundantly obvious anyway.

Likewise, when programming, if I reuse some variable very often in a short space, I will temporarily rename it to something single-lettered, e.g. "s = volumeScalingFactor; x = s; y = s; z *= s".

I think maths style vs. programming style is only one factor here, with the other simply being this application of DRY: describe one-off things well, but shorten their names if they're oft-repeated within a given context.

Maths tends to reuse the same variable for a lot of different operations in a single context whereas programming doesn't as much, which naturally leads to this single-letter name vs. long name difference in styles.

Re: How Developers Choose Names

#155

Post by wvenable » Mon, Apr 19, 2021, 4:36 PM UTC

augustk wrote: post #150

wvenable wrote: post #145

Earlier quoted context omitted.

Like other's have said, I might use "Get" to signify that this is a complex operation. Although I prefer more descriptive words like "Fetch" or "Find". So FetchInstances() is expensive (each time it's called) but the property Instances is cheaper or only expensive on the first access.

But then the name of the function is somewhat tied to its inner workings. What if you change the implementation so that it returns a cached value? To quote Michael Caine, an interface should "Be like a duck. Calm on the surface, but always paddling like the dickens underneath."

> But then the name of the function is somewhat tied to its inner workings.

Not necessary tied to it's inner workings but more tied to how you should use it. There are good reasons that a function might not cache it's value -- maybe because you want that fresh data each time. The name is the signal to the user how they should use it. I expect an "Instances" property to give me the same values each time. However with "FetchInstances()" I would store that result in my own variable if I want to keep referring to those instances.

> What if you change the implementation so that it returns a cached value?

That's a different function then. The semantics have changed significantly.

Re: How Developers Choose Names

#156

Post by nitrogen » Mon, Apr 19, 2021, 8:27 PM UTC

kuang_eleven wrote: post #137

nitrogen wrote: post #109

Earlier quoted context omitted.

When two people strongly hold the opposite opinions on the same team, it can be a massive hassle for absolutely zero benefit. On teams, or in life in general, IMO when there is no consensus, or even an anti-consensus, the only rational global decision is not to make a global decision.

I cannot disagree strongly enough, this is how you end up working on teams that are just disconnected, hostile fiefdoms. Solving an issue that is intractable via discussion is when you escalate. Probably to a tech lead, or even to a manager.

Maybe we're talking about different kinds of issues. In the context of opinion-based disagreements (rather than matters of fact or evidence), an anti-consensus seems to indicate that there isn't (and can't be) one right answer. If one group imposes its will on another group, or appeals to the powers that be to do so on their behalf, the second group will definitely become hostile to the first. Thus, anything other than "agreeing to disagree" and moving on to areas where you do agree would just build more resentful, disconnected hostility.

Re: How Developers Choose Names

#157

Post by 3grdlurker » Tue, Apr 20, 2021, 3:32 PM UTC

TechBro8615 wrote: post #82

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.

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

It’s not premature optimization, it’s just boilerplate because it’s a pattern that happens so often.

Besides, there’ll be less work if the requirements do in fact change, and there’s nothing wrong with accounting for the possibility of change when you’re writing code because what you write now constrains what you can write in the future.