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

131–140 of 157 posts

Re: How Developers Choose Names

#131

Post by marshallward »

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

Just to quickly clarify: eigenvectors are not named after a person. It's a German word meaning "own" or "inherent" and was meant to denote something which resembled itself.

https://hsm.stackexchange.com/questions/5563/where-does-the-...

https://jeff560.tripod.com/e.html

Re: How Developers Choose Names

#132

Post by 1vuio0pswjnm7 »

ineedasername wrote: post #123

I just use a UUID for every variable name to make sure the codebase never has any ambiguity. No one is going to confuse e7693160-b5cf-4761-9202-de019cfd0fc9 with c3d8b9ac-d0da-4bbc-912b-025ce4e47f62

You could rename the functions to match their symbols, after compiling.

The output of nm for the function originally named "write" from musl libc might look like

   000000000006ee20 T 000000000006ee20

Re: How Developers Choose Names

#133

Post by Forge36 »

MattRix wrote: post #86
Forge36 wrote: post #36

Earlier quoted context omitted.

onClick => onAccept => submitRequest The downside is lots of little functions, the plus side is smaller behaviors. (Ie avoiding 5 levels of nesting in a single function.)

This sort of thinking leads to codebases that are too abstract, where it’s hard to follow the flow of execution. There’s nothing wrong with 5 levels of nesting. It’s much easier to follow than 5 separate functions.

Depends on the size of the function. If these are literal one liners: don't break them up. When they are shared between multiple pieces it's more useful. Ie: submit request has multiple callers.

Re: How Developers Choose Names

#134

Post by patrick451 »

uyt wrote: post #127
amelius wrote: post #99

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

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 more recognizable in place.

This zealotry a lot of devs have over descriptive names needs boundaries.

Re: How Developers Choose Names

#135

Post by stevebmark »

ineedasername wrote: post #123

I just use a UUID for every variable name to make sure the codebase never has any ambiguity. No one is going to confuse e7693160-b5cf-4761-9202-de019cfd0fc9 with c3d8b9ac-d0da-4bbc-912b-025ce4e47f62

There's some usefulness in this idea, which is the core idea behind Unison https://www.unisonweb.org/docs/tour

Re: How Developers Choose Names

#136

Post by 8note »

codr7 wrote: post #110
augustk wrote: post #103

Earlier quoted context omitted.

I have never understood the practice of using a verb phrase ("get") for functions with no side-effects. To me it makes more sense to name the function after the result, i.e. Instances , InstanceIds , AllInstanceIds etc.

The advice I once got and since internalized is to reserve 'getX' to give a hint that something happens besides returning 'X', lazy initialization is a common use case.

I think of ensureX as getting x whilst initializing it if needed

Re: How Developers Choose Names

#137

Post by kuang_eleven »

nitrogen wrote: post #109
city41 wrote: post #58

Earlier quoted context omitted.

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.

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.

Re: How Developers Choose Names

#138

Post by calvinmorrison »

whatshisface wrote: post #124
ineedasername wrote: post #123

I just use a UUID for every variable name to make sure the codebase never has any ambiguity. No one is going to confuse e7693160-b5cf-4761-9202-de019cfd0fc9 with c3d8b9ac-d0da-4bbc-912b-025ce4e47f62

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?

Re: How Developers Choose Names

#139

Post by dragonwriter »

crazygringo wrote: post #119
samatman wrote: post #111

Earlier quoted context omitted.

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

> First, I don't know what it means to "shadow" the possessive.

“Adopt a plural form identical in form to the possessive so as to create avoidable ambiguity between the two.”

(Incidentally, that’s why the Times shouldn’t do it either, even if context will usually disambiguate it.)

> And since a possessive necessarily precedes another noun

Not necessarily a simple noun, though, it could be a noun phrase. In practice, this will usually be disambiguated by context still, but merging the possessive and plural means that there will be more situations where you have to process more context to disambiguate meaning, which distracts from whatever your purpose was in reading the material in the first place.

Reducing the inherent redundancy in natural language reduces quality and clarity of communication.

Post reply on HN