box.measures.sides['left-bootom']
vs
measurementOfLeftBottomSideOfBox
I know your point is elegant vs readable which I agree I just want to note another dimension that could be flat vs well structured data.
box.measures.sides['left-bootom']
vs
measurementOfLeftBottomSideOfBox
I know your point is elegant vs readable which I agree I just want to note another dimension that could be flat vs well structured data.
The only reason you would want to structure your data like that is if you want to think about the Box as a whole from a more abstract level.
But there's nothing wrong with writing an entire app that focuses on the measurement of the left bottom side of a box. If that's the requirement, than there's no need to define the measurement as part of a higher order type "Box" if you're not doing anything with the other measurements.
No. If my program only modifies the left bottom side of the box it doesn't need the whole box defined. In this case and many cases similar to this, it's totally fine encoding more verbosity into the naming of the integer.
The "smell" your sensing here is only called a smell because you can't logically explain it. Your brain is firing off a false alarm.
I can easily make a variable name that can trigger the false alarm but you won't be able to come up with a reasonable nested structure to contain it.
theColorOfTheSkyOnAThursdayAt6PM = "ReddishOrange"
What are you gonna do here? I have a string that represents a color of the sky at a certain day on a certain time. What structure can reasonably contain this concept and ONLY this concept. Unless you want to define a structure called Sky the long name is the only possibility.