3 ms·
> 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
by olejorgenb 6y ago
> 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.
- nendroid 6y agoYou 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