struct BoxDimensions {
        topLeft, topRight, bottomLeft, bottomRight
    }

I agree it is a better name. My version was deliberately designed to hurt your eyes to show you that the pain is just psychological. There is no intrinsic difference between your naming versus mine other than mine takes a millisecond longer to read the longer names. My version is quite ugly as well, but ugly naming has no negative effect on your code. It's all about understandable naming.

Not every concept can fit into a beautiful name as you did here. What if the box was a very specific box out of many boxes and I needed to specify the details?

   DimensionsOfBlueBoxFromRoom253 = { ... }

>The second only need a glance, the first you have to read/scan multiple times to dig out which delta it is.

That's only because you already know what Dim means. Many many times I see abbreviations that are unknown. For example:

   TranBox.Dow

Would it be clear to you that Trans means translation and Dow means down?

>Code with longer names are harder to scan.

Same with english. It's a small price to pay but people tend to enjoy reading english more than programming abbreviations and shortcuts. You spend an extra second reading a line, but you gain much more clarity about the intention of the programmer. Where with an abbreviated name you can often be unsure of what the programmer meant and you'd have to dig into the surrounding context.

       trueBox.bottomLeft - measuredBox.bottomLeft

See? already I don't even know what you mean by true. True can mean anything. Could it be you're referring to a box with the the word true printed on it? A layman will not understand the difference between a truebox and a measuredbox. The below is infinitely better:

       BoxWithEstimatedDimensions
       BoxWithActualDimensions

Perhaps it's ugly and offensive to your aesthetic tastes, but there's zero ambiguity here. In fact I would use snake case for even more clarity:

      Box_with_Estimated_dimensionS

That variable name is not elegant but there is literally zero way I can misunderstand the meaning. Note how I combined snake case with alternating camel case above. This really pisses some people off, but when you think about it mixing camel case with snake case is just aesthetic bs that have nothing to do with the ultimate goal of your programming style: Readability. Also note the capital S at the end of the name. Believe it or not the capital S has ZERO effect on the quality, readability and even the verbosity of your source code yet this is what programmers will bitch and moan about the most.

>The second one is just exhausting to me at least.

Exhausting like the english language is exhausting? Exhausting like commenting your code is exhausting? People don't complain about the verbosity of English and all I'm suggesting is bringing the verbosity of programming a bit closer to English so that the understandability of your code is ALSO closer to english.

> My version was deliberately designed to hurt your eyes to show you that the pain is just psychological. There is no intrinsic difference between your naming versus mine other than mine takes a millisecond longer to read the longer names. My version is quite ugly as well, but ugly naming has no negative effect on your code. It's all about understandable naming.

..let's jump back a bit to something else you said:

> First off this "clutter" exists in the English language itself yet I hear no one complaining. I don't communicate with other people using shortcuts and context aware abbreviations like your suggesting.

This level of clutter doesn't exist in the English language, because we do use the contextual shorthand GP is leanings towards all over the place. I'm fairly sure you do the same, but possibly aren't aware of doing it because it comes so easily in natural language.

For example, using this paragraph from the Wikipedia page on Romeo and Juliet:

> Juliet visits Friar Laurence for help, and he offers her a potion that will put her into a deathlike coma or catalepsy for "two and forty hours". The Friar promises to send a messenger to inform Romeo of the plan so that he can rejoin her when she awakens. On the night before the wedding, she takes the drug and, when discovered apparently dead, she is laid in the family crypt.

And changing it to use your insistence on descriptive names with "cluttered English" instead of contextual shorthand, it becomes:

> Juliet Capulet visits Friar Laurence for help, and Friar Laurence offers Juliet Capulet a potion that will put Juliet Capulet into a deathlike coma or catalepsy for "two and forty hours". Friar Laurence promises to send a [independent] messenger to inform Romeo Montague of the plan so that Romeo Montague can rejoin Juliet Capulet when Juliet Capulet awakens. On the night before the wedding [between Romeo Montague and Juliet Capulet], Juliet Capulet takes the coma drug and, when discovered and apparently dead, Juliet Capulet is laid in the Capulet family crypt.

(parts in [] I'm unsure about because it's been so long since I've read/seen the play)

Long identifiers are exhausting to read, even with native speakers, because of the heavy repetition that has to be read and discarded with every single use. It's why we don't speak or write like in that second example.

Man of course there are english passages that are too verbose to read. Everyone knows this. This is not what I'm talking about. I am saying the level of NORMAL verbosity in the english language is already illogically considered to be too verbose for programming. There is an irrational dichotomy here and you can't see it.

You took shakespeare and upgraded it to be more verbose than normal. That example does not disprove my point because you misunderstood.

Let's start with a normal example. My original Box example. Step by step. It is in your opinion that the Box example I created is waaay to verbose. My claim is that IF I translated my Box example into the English language it will not be considered Verbose by the average english speaker. Take this english phrase:

  The measurement of the left bottom side of the box is 26 centimeters. The right upper side of the box is 10 centimeters. 

We can both agree the level of clutter above is Normal for the English language. I can shortcut it though if you want.

   Box: x is 26, y is 10.

The second example is the shorthand we tend to use in programming. We think it's fine in programming but it's not fine in English.

   struct Box {
       x = 26,
       y = 10
   }

English in 99% of all cases, we prefer way more verbose syntax than programming, even just by the virtue of grammatical words like "the" "and" or "of". My argument is to move programming more in the direction normal english verbosity. That's all. Add more meaning to your variable names, spell out the purpose of the name.

I'm not advocating insane levels of obvious of detail here. I'm obviously not saying we do this:

    variableThatCanBeAddedToOtherNumbers = 22

which is what your example is accusing me of.

I'm saying fill in the variable name with necessary details that the reader would need to know. Fill in details in your variable name that you would put in documentation to help the reader understand. This is what they call self-documenting code. Additionally there is no need to cut details for elegance, it is pointless to use an abbreviation if that abbreviation has a probability to be misinterpreted or confusing.

UpperLeftSideInCentimeters is infinitely better than x as x can lead to a ton of confusion. Either way nobody will call something "x" in english they'd choose the more verbose and informative way despite the "exhaustion" in reading. On average nobody complains about English so the same can be said if we did it in programming.

Additionally programming will never approach the verbosity of English. I'm just saying programming needs to be a bit more verbose and not excessively more verbose than English itself.

> My version was deliberately designed to hurt your eyes to show you that the pain is just psychological

Are you saying that psychological pain is not real? :D

> Where with an abbreviated name you can often be unsure of what the programmer meant and you'd have to dig into the surrounding context.

But this is context you'll usually need to acquire to work with the code anyway. (abreviations can definitively be overdone though)

I agree that code should strive to require little context to understand, but there is a trade-off. In some sense: if the name encodes the whole context there's no need for the name in the first place:

     function area(widthOfBox, heightOfBox) { return widthOfBox * heightOfBox; }

     widthOfBox_times_heightOfBox = area(widthOfBox, heightOfBox)

I began to write the above as a volume function of the box we've been talking about, but realized I don't really know what kind of box it is. Then I realized it might be a 2d box, not a 3d box? But then the names doesn't really makes sense? (I guess measurementOfBottomFrontSideOfBox, etc. was omitted for brevity)

So even this crucial information is missing from the names and require context. Which isn't necessarily that bad, since in any real scenario it would likely be included in the minimum-viable-context.

You want to encode as much context into the name as possible without breaking abstraction. Meaning that the definition of the function should not be part of the name. Only the API of the function and context should be encoded into the name.

So for example:

    areaOfTwoDimensionalBox

is better than:

    area

is better than:

   widthOfBox_times_heightOfBox