Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Taming names in software development

simplethread.com

Post reply on HN
Print view View original

21–30 of 44 posts

Re: Taming names in software development

#21

Post by rTX5CMRXIfFG »

wging wrote: post #16
TheFattestNinja wrote: post #3

"In software, really good names are meaningful, descriptive, SHORT, consistent, and distinct." (emphasis mine) I hate this general reccomendation style that names need to be short. This only made sense in the old times of programming where you had to actually type them. The reality of IDE's bringing all forms of intellisense and autocomplete means you almost never type a name out, thus being short brings no benefit i…

I disagree. The utility of short names is not just that it takes less effort to write them. They're also far easier to read and understand. IDE autocompletion doesn't help with that, nor does any other tooling, really. Since code is read much more frequently than it's written (including but not limited to any time that related code has to be changed), names should be as short as possible without sacrificing clarity.…

The problem with `timeoutMs` or `timeoutSecs` is that if you have a policy that you shouldn't contract words (possibly founded on a first principle that you value clarity in your coding standards), then you're going to spend time justifying why a pull request gets rejected when someone names a type `SearchCntrlr` or `SubmtBtn`. Before you know it, you'll have spent hours just debating and getting no work done, whereas you wouldn't have the problem if you just spelled out `timeoutInMilliseconds` or `timeoutInSeconds` fully.

I mean, what value do the shortenings `ms` and `secs` provide, anyway? Saving keystrokes? You could still type our `timeoutms` and the IDE's autocomplete would suggest it for you, right?

Re: Taming names in software development

#22

Post by kitd »

In JavaScript, you’ll often see i, j and subsequent letters as iteration variables. i is not descriptive, and j is somehow even less so.

Using i & j etc for indices dates back to older versions of FORTRAN where the variable type depended on the first character of the name, with i- n reserved for integers.

Quite why the convention has persisted for so long is one of SW Engs little mysteries.

Re: Taming names in software development

#23

Post by furyofantares »

kitd wrote: post #22

In JavaScript, you’ll often see i, j and subsequent letters as iteration variables. i is not descriptive, and j is somehow even less so. Using i & j etc for indices dates back to older versions of FORTRAN where the variable type depended on the first character of the name, with i- n reserved for integers. Quite why the convention has persisted for so long is one of SW Engs little mysteries.

Surely it predates that as well, I assume FORTRAN chose ijklmn as the integers due to i,j,k being used as indices in mathematical convention, (as well as n for sequences and m,n for matrices.)

Re: Taming names in software development

#24

Post by furyofantares »

> I understand exactly what BasicReviewableFlaggedPostSerializer is on my first time seeing it.

I don't. I think I figured it out after reading it half a dozen times (except for Basic, no clue there) before working out that Post is probably a noun. So even this requires context to just read and know what it does, my first read of it I only knew what Serializer meant.

Re: Taming names in software development

#25

Post by anon121122 »

beeforpork wrote: post #17

How locally a variable is used should matter for selection of a name, too. I don't find i, j, k, o, p, k, v at all offensive if their scope is just a few lines of code. Usage is often idiomatic (e.g., k, v for iterating a map or i for an integer loop variable) and using a longer name would just make it less idiomatic and less obvious.

This makes a lot of sense.

I also prefer for-loops that uses "i". It is instantly clear that "i" is the current index used by the loop. Even though it is a single character variable name, it has a specific meaning by convention.

If I see a variable named "people_result_list_index" it actually hurts the readability. I don't know that it actually is local to the for-loop, as it could have been defined anywhere in the code or even passed as an argument to the function. It actually hurts readability and adds complexity.

Using "i", "k", "v" and other single character variables outside for-loops is often not advisable. An exception to this could be "x", "y" and "z" if they refer to positions in 2D / 3D space. Personally I would probably wrap them in a structure, so that you could refer to them as pos.x and pos.y. But I wouldn't hold it against someone if they thought the code was readable without it. It is basically part of the domain knowledge. Other domains may have similar exceptions. The "R" value in terms of growth rate comes to mind.

TLDR; Single character variables can make sense in the right context, when they are used as part of a convention or domain terminology

Re: Taming names in software development

#26

Post by furyofantares »

furyofantares wrote: post #24

> I understand exactly what BasicReviewableFlaggedPostSerializer is on my first time seeing it. I don't. I think I figured it out after reading it half a dozen times (except for Basic, no clue there) before working out that Post is probably a noun. So even this requires context to just read and know what it does, my first read of it I only knew what Serializer meant.

Or maybe I'm still not getting it, my read is there are posts, they can be flagged, flagged posts can be reviewed, and this is a "basic" serializer for flagged posts that have yet to be reviewed.

But why you'd need such a specialized serializer is beyond me, (let alone presumably less basic one as well) it seems like such drastic overkill that maybe I still don't get what the name means.

Re: Taming names in software development

#27

Post by DrBazza »

natch wrote: post #2

What this misses — and every other article I’ve seen about naming misses — is that the truly hard part of good naming is none is the stuff that was mentioned. The hard part is this: taking the deserved level of care with naming often has to be done in a context with other humans who wrongly think that it’s simply not that big a deal, and their annoyance with having it brought up becomes an often unspoken source of fr…

Naming is simple when the function or method is simple.

Complex naming is often, but not always, a good indicator of complexity.

Unless of course, it's Java... https://projects.haykranen.nl/java/

Re: Taming names in software development

#28

Post by mysterydip »

natch wrote: post #2

What this misses — and every other article I’ve seen about naming misses — is that the truly hard part of good naming is none is the stuff that was mentioned. The hard part is this: taking the deserved level of care with naming often has to be done in a context with other humans who wrongly think that it’s simply not that big a deal, and their annoyance with having it brought up becomes an often unspoken source of fr…

I used to think descriptive variable names were a waste of time (a,b,c, even things like booya, foo, etc), until I had to maintain my own code from years ago. I literally had no one to blame but myself for the extra deciphering work I had to do.

Re: Taming names in software development

#29

Post by maccard »

dmurray wrote: post #15
thaumasiotes wrote: post #8

Earlier quoted context omitted.

> but let’s not stop calling ... the database temmp_v3_old_Udpate_RstdnewV2 I worked briefly on a codebase that was otherwise produced by Chinese programmers (in China). It did feel somewhat surreal seeing variable names that were in English but misspelled, particularly when e.g. several classes all had a field of the same name, except that in one of them, the name was misspelled. I assume it didn't bother them becau…

I've seen the same thing many times with English-speaking programmers. Plenty of people just don't spot that 'udpate_history' is misspelt.

And sometimes that mistake propagates and leaves us 25 years later still using referer [0]

[0] https://annaken.github.io/a-brief-history-of-the-referer-hea...

Re: Taming names in software development

#30

Post by maccard »

kitd wrote: post #22

In JavaScript, you’ll often see i, j and subsequent letters as iteration variables. i is not descriptive, and j is somehow even less so. Using i & j etc for indices dates back to older versions of FORTRAN where the variable type depended on the first character of the name, with i- n reserved for integers. Quite why the convention has persisted for so long is one of SW Engs little mysteries.

> Quite why the convention has persisted for so long is one of SW Engs little mysteries.

I like it - it's a convention that has clear context once it's initially understood. It saves the argmuent of "is it an index, counter, loop iterator, " - it's the i/j/k'th loop's index.

Post reply on HN