>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 th

>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.