[TheFattestNinja]

"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 if not "habit". You should really try to have understandable names, detailed names, but not care about shortness. "timeout" is a good variable name if you language has some great type system and your coding works with that. "timeoutInSeconds" is a better one if you are just using an int/long to distinguish it from "timeoutInMillis" and avoid silly mistakes.

[wging]

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. Excessively long names are harder to parse, and can slow you way down when trying to understand code.

(I'm arguing against what I see as your central point, but to be fair, 'without sacrificing clarity' is doing a bit of work in the paragraph above... your example is actually a good case of a bit of additional length being actually worth it. I would say timeoutMs or timeoutSecs are good shorter alternatives, "ms" and "secs" being widespread and clear abbreviations. You're completely right that 'timeout' is insufficiently clear for a purely numeric type, though I'd disagree that you need all that much type system magic to make it OK. For example calling a `java.time.Duration` `timeout` seems fine.)

[rTX5CMRXIfFG]

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?

[zeroimpl]

Also is it timeoutMs, timeoutMS, or timeoutMillis?

[ParetoOptimal]

> thus being short brings no benefit if not "habit".

IPersonallyFind tonsOfCode likeThisReally hardToParse, especially when the least important parts have the longest names.

As a result code like that can be overwhelming and sometimes make me dread working with it.

[Falkon1313]

I find they also often indicate over-abstraction or over-complicated generic stuff that is often kind of irrelevant to the domain.

Equipment_Maintenance_Criteria isn't super short, but it appears to actually mean something. Definitely tells you more than just "Selection" would. But all too often it's called something like AbstractServiceFactoryBuilderManagerLocatorPlugin which really doesn't tell you anything at all and leaves you at the end knowing less than you did when you started reading it.

[tartoran]

Yes, long names can be taxing too if taken to extremes. I use descriptive names that spell out the domain or business logic so code becomes as close to self documenting as it gets. However, locally when I have to reference these multiple times I use a short alias, usually the acronyms of the long names so it’s the best of both worlds: don’t have to carry around the long names everywhere but still have a fallback on them when I forget what they represent.

[ipaddr]

do_you_prefer_underscores? iKindOfDo i_kind_of_do

[teddyh]

In Emacs: M-x glasses-mode

[hakunin]

Long names should be a signal that you’re breaking away from current context or doing something unusual. Unnecessary length and redundant context makes names more difficult to discern. I wrote about it a bit more in the “what?” section of this post: https://max.engineer/maintainable-code

[blowski]

Perhaps "short" is a shorter way of saying "quick to parse". Even with IDEs, I still want that, lest I end up having to choose between names like this all the time:

- MinimumPriceCalculatorFactory

- MinimumPriceCalculatedPriceFactory

The extra couple of seconds every time becomes distracting and irritating.

[jffhn]

In small methods I tend to use shorter names, even very short non-descriptive names, because there is less context so less chance of confusion, and it makes it easier to see what's going on in a glimpse (and check it matches method name).

On the other hand, if some public method does multiple things that need to be known to decide where it can be called, I put them all in its name.