>Look at how many much useless text we have here. "measurementOf" and "SideOfBox" add nothing but clutter to the naming, and writing out practically the same thing 4 times suggests we could abstract this into a data structure.

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. I literally say "here are the measurements of the box" both in written documentation and by sound, what black magic says that this is so wrong to do in code?

Anyway here it is:

   struct measurementsOfBox = {
        measurementOfLeftBottomSideOfBox
        measurementOfRightBottomSideOfBox
        measurementOfLeftTopSideOfBox
        measurementOfRightTopSideOfBox
   }

There is Nothing wrong with above code. Clutter doesn't harm readability it just harms aesthetics. And useless? Are you sure? Even if it was useless what harm does it do?

Now you could argue that the clutter itself can hurt reading efficiency. But honestly think about it. That's like 5 seconds of extra reading out of your life. It's not a big deal.

Most programmers just have this version of OCD. I get it the struct looks really ugly, but there is nothing logically wrong with it.

I mean you could make it more elegant like this:

   struct Box {
      x
      y
      z
      t
   }

But this could lead to all kinds of other issues. For example because I didn't label anything with "measurement" now the reader can mistake the values for the "positioning" of the box as opposed to "measurements" of the box.

You made a common mistake here in your naming in assuming that "measurement" was a useless prefix. It's not... but that's besides the point because every program writer can make that mistake. That's why when you add a bit more clarity to your naming you have a larger chance to avoid this mistake at a small cost of adding some ugliness to your code.

>1) It's overly verbose. More than 3 words is a warning sign to me.

Warning sign of what? It's a similar warning sign that your brain fires off when you're alone in the dark in the woods. There's nothing to fear logically but your brain kicks off warnings regardless. Same with this, your brain kicks off some sort of warning but when you work it out logically there's Nothing. Verbose code is not bad just like verbose documentation is not bad.

>2) It's specific rather than generic. For instance if I name a function "sortSheepByHoofSize", it implies the reader know what hoofs are, cares about them and knows how to measure them. Whereas when naming it "sortSheep" or perhaps even just "sort", it's immediately understandable on a surface level to practically everyone.

Data referring to a specific concept or a generic concept is a structural decision made by you. I chose data referring to a specific concept. This happens in code. Not everything is generic and for specific things there's nothing wrong with using very specific names.

>3) Following on from 2), this type of naming lacks context. We should leverage the context of surrounding code and abstractions to make naming understandable, instead of trying to pack all the meaning into one name. Oftentimes there's repeated information in names that could be inferred from context instead.

>>We should leverage the context of surrounding code and abstractions to make naming understandable, instead of trying to pack all the meaning into one name.

There's no downside into packing more info into a name. Sure it can get to a point where it's unreasonable but in general there's nothing wrong with me calling something a measurement when that's what it is... This is an aesthetic issue that programmers react due to human bias, but there's nothing intrinsically wrong with prefixing measurement onto box. There's nothing wrong with repeated information either.

By prefixing measurement onto the Box struct I let everyone know that these are measurements on the box and not the position of the box. It's ugly but ugliness has nothing to do with readability or structure.

This is the bias programmers need to get rid of.

Find beauty in the structure of your code and find readability in the naming. Don't make the mistake of trying to find beauty in naming. Nobody wants to decipher code with poetic naming.

Have you guys heard of literate programming by donald knuth? He's taking what I'm talking about to extreme heights.

x, y, z, t is not the suggested alternative. leftBottom, rightBottom, was clearly the intended alternative. A "Length" suffix could be added to make it clear it's not coordinates, but I think it's better to encode this into the struct naming:

    struct BoxDimensions {
        topLeft, topRight, bottomLeft, bottomRight
    }

In code working with these objects it's likely both obvious and necessary to know that the code works with dimensions. Ie.: being reminded of this each time you encounter a variable it just noise.

Code with longer names are harder to scan.

   boxDim.measurementOfLeftBottomSideOfBox - boxDim.measurementOfRightBottomSideOfBox

vs

   boxDim.bottomLeft - boxDim.bottomRight

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

If it's important to distinguish between measurements and true values it would be better to encode this in the struct variable name. Having distinct types for measurements and true value would be a hassle no?

    trueBox.bottomLeft - measuredBox.bottomLeft

vs

    trueBox.trueLengthOfBottomLeftSideOfBox - measuredBox.measurementOfBottomLeftSideOfBox

The second one is just exhausting to me at least.

  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