[nl]

You are completely misrepresenting what McConnell says.

There is a summary of his advice here[1], but just to highlight

Describe everything the routine does And we mean literally everything. If that makes the name ridiculously long, the name isn't the problem. Your routine is.

And

Make names as long as necessary According to McConnell, the optimum name length for a variable is 9 to 15 characters; routines tend to be more complex and therefore deserve longer names. Make your names as long as they need to be in order to make them understandable.

I've read McConnell, and your claims are so completely the opposite of what he recommends that I'm still unconvinced you aren't trolling.

[1] https://blog.codinghorror.com/i-shall-call-it-somethingmanag...

[geocar]

I don't agree with everything McConnell says, but if you have it handy, note at page 173:

"A study from Basili and Perricone found that routine size was inversely correlated with errors: as the size of routines increased (up to 200 lines of code), the number of errors per line decreased (Basili and Perricone 1984).

And the conclusion (on page 174): …None of the studies that reported decreased cost, decreased error rates, or both with larger routines distinguished among sizes larger than 200 lines, and you're bound to run into an upper limit of understandability as you pass 200 lines of code

With that in mind, consider that KDB's SQL92 interface is 35 lines (the parser is 14 lines). It may be an extreme example of what McConnell is observing, and yet was himself unable to learn from.

> I'm still unconvinced you aren't trolling.

Look at it this way: Here is software that is faster than what you can write (or maybe you want to write your own taxi problem implementation), and if you don't try hard, you will miss out in finding out how to do something that you can't do.

That downvote button is so easy, that internet person is just a troll, I've been programming for ages, so of course I know what I'm talking about, but if you look through my comment history, you might find it easier to convince yourself at least that I believe that program length matters and permit yourself a discussion about it. You might learn something.

* https://news.ycombinator.com/item?id=8476294

* https://news.ycombinator.com/item?id=8477064

* https://news.ycombinator.com/item?id=10872209

and so on.

[nl]

Ok, I accept you aren't trolling :)

I find it difficult to agree that using non-representative names for variables or functions improves understadability.

Notably, using something like x to represent a meaningful value means the brain has to hold the mapping between the two, which will decrease the number of useful pieces of information kept in short term memory[1].

The brain doesn't keep track of the number of characters in a variable name.

[1] http://www.psych.utoronto.ca/users/peterson/psy430s2001/Mill...

[geocar]

So icsa[1] said something interesting on this point:

The issue, for me, is not readability but context. Even a word or two (e.g. cuts, begins, dims) helps greatly to establish the context of the code. Like having a map before hiking.

A comment can clearly provide that context without making the variable names long.

[1]: https://news.ycombinator.com/item?id=8747314

> The brain doesn't keep track of the number of characters in a variable name.

Surely you must appreciate that if we use too many characters the window will scroll?

[shitgoose]

long names are distracting. try using short names for variables where code requires scrolling and very short name for variables in short blocks of code (where you see the context without scrolling). something like 'idxLS' instead of 'indexOfLastSlash'. Or x+=totalsMst[i] instead of accumulatorOfTotalValues+=totalValuesFromMasterList[i] if this is the only line in a loop.

as your opponent has mentioned, context is the key. you operate with objects in your brain, and the faster the transition from code element to the brain object, the better you understand the code. long names make this lookup unnecessarily difficult.