I like to use "big-endian" naming molds (love that term!) to define sets of names that when you alphabetize them place related variables next to each other. (i.e. in a completion menu or browser.)
For example, left_foo and right_foo are little-endian, since the least significant word comes first, so they'll be a long distance away from each other in an alphabetized list.
But foo_left and foo_right are big-endian, since foo is more significant than left or right. So they will appear one after the other in an alphabetized list.
Common suffix words are _x _y _z or _min _max, or _left _right _top _bottom, of even singletons like _enabled _loaded _error etc.
But when you combine multiple dimensions together in names, you need to think of which dimensions are more significant, based on how the variables are used, so use foo_x_min foo_x_max, if the positions are important, or foo_min_x foo_min_y, if the ranges are more important.
Sometimes it's hard to decide or ambiguous, so just try to be predictable and the same as all the other code. Think of which variables should appear closest to each other in an alphabetical list.
And avoid middle-endian or random-endian (or sentence-grammar-order-endian) like the plague. A variable name should probably not be a grammatically correct sentence.
Another really annoying linguistic naming smell is "smurfing," where all of class Smurf's instance variables have smurf_ prefixes. Or where all the classes, methods, or instance variables have an "xyz_" prefix where "xyz" is the name of the project or library. Arrgh!!!
I really like this concept but I find it a bit frustrating that the name for the naming convention doesn’t follow its own convention. Shouldn’t it be called “endian-big”? ;)
Also from an LTR standpoint why is it big-endian when the left is not the end but the start? so it should be big-startian or, according to you, startian-big.
There's an interesting question that arises when you says "when you alphabetize them place related variables next to each other".
Let's say you have some non-trivial class that includes, among others, some 2d rectangular data: An x, y, width, and height. They're all related, but they don't naturallly occur near each other without a little massaging:
coordX, coordY, sizeWidth, sizeHeight?
xMin, xMax, yMin, yMax?
coordXMin, coordXMax, coordYMin, coordYMax?
I generally agree with your sentiment, but there's a reason "naming things" is one of the hardest problems in computer science :)
I'm not quite able to verbalize exactly why, but when I see the set of { "coord", "x", "min" }, it sounds to me like the most intuitive way to put it would be "x_coord_min", but this seems to violate the rule that GP gave, since "coord" here seems to be "greater" than "x" given that "x" is an answer to "what kind of coordinate?". The best explanation I can come up with is that "x coordinate" feels like a coherent logical unit and that splitting it would make it more work for me to parse as a reader, and then "min" follows that because "min_x_coord" sounds like it would be something like the "minimum x coordinate" for a given window or something. I wish I could come up with some consistent universal rule for how to order these things, but I can't really come up with any other process to describe how to get what's the most intuitive other than "look at all of them and see what sounds right". I guess it's not unreasonable to say that ordering three "words" is fairly easy to brute force looking at all of them, and beyond that it's probably worth reconsidering the naming (and perhaps scoping) of the variables you need to disambiguate, but it's not nearly as satisfying as having some sort of objective rule.
"Smurfing" and "big-endian" are the same thing though!
IMO a big alphabetical list of everything in your project is not a useful or important thing. Use a language that has good support for hierachical namespaces, and use them.
I think big-endian naming was useful for programming with editors that supported tab completion. At one point, the suggestions were only displayed alphabetically. Nowadays, editors use a more sophisticated algorithm (is there a name for it? Fuzzy search, perhaps?) that suggests words containing the sequence of characters already typed anywhere within it.
For example, left_foo and right_foo are little-endian, since the least significant word comes first, so they'll be a long distance away from each other in an alphabetized list.
But foo_left and foo_right are big-endian, since foo is more significant than left or right. So they will appear one after the other in an alphabetized list.
Common suffix words are _x _y _z or _min _max, or _left _right _top _bottom, of even singletons like _enabled _loaded _error etc.
But when you combine multiple dimensions together in names, you need to think of which dimensions are more significant, based on how the variables are used, so use foo_x_min foo_x_max, if the positions are important, or foo_min_x foo_min_y, if the ranges are more important.
Sometimes it's hard to decide or ambiguous, so just try to be predictable and the same as all the other code. Think of which variables should appear closest to each other in an alphabetical list.
And avoid middle-endian or random-endian (or sentence-grammar-order-endian) like the plague. A variable name should probably not be a grammatically correct sentence.
Another really annoying linguistic naming smell is "smurfing," where all of class Smurf's instance variables have smurf_ prefixes. Or where all the classes, methods, or instance variables have an "xyz_" prefix where "xyz" is the name of the project or library. Arrgh!!!