I once worked with an absolutely horrendous programmer named "Sam" who enjoyed the smell of his own farts so much that he he always smurfed his own name or possessive prefixes like "sams_" and "my_" in variable and function and file and form field and database column names.
And he loved to get "artistically creative" with "elegant variation" of variable names and naming conventions,
permuting and mutating them at every level, and making up cute unique abbreviations by randomly dropping characters to save a few keystrokes of typing, then spicing it up with whimsical nonsense like "aardvark" and "pancake", instead of boringly predictable consistent correctly spelled descriptive big-endian names like I prefer. (He claimed that made it easy to grep the code.)
He would even alternate between CamelCase and lowerCamelCase and snake_case and Snake_That_Ate_A_Camel_Case and UPPER_CASE and runtogetherlowercase in the same fucking variable name, occasionally throwing in the random "sam_" and "_SAM" prefixes and suffixes for good measure!
He also liked hard wiring the path of his home directory into code, of course. He was like a territorially possessive dog pissing on all the trees and fire hydrants he could find, and all the code he wrote sucked.
That made it extremely hard to separate the "arteest" from their "work", and not to criticize the person as well as the code. But at least it was easy to tell at a glance which code needed to be tossed out and rewritten.
Please don't be a Sam! There are some people who do deserved to be criticized as much as their code.
Elegant Variation (which is a terrible idea despite its fancy sounding name):
>Elegant variation is a writer's substitution of "one word for another for the sake of variety". The term was introduced in 1906 by H. W. Fowler and F. G. Fowler in The King's English. In their meaning of the term, they focus particularly on instances when the word being avoided is a noun or its pronoun. Pronouns are themselves variations intended to avoid awkward repetition, and variations are so often necessary, that they should be used only when needed. The Fowlers recommend that "variations should take place only when there is some awkwardness, such as ambiguity or noticeable monotony, in the word avoided".
Big-Endian Naming Molds, Code Smells, Smurfing:
Felienne Hermans: How patterns in variable names can make code easier to read
DonHopkins on May 22, 2022 | parent | context | favorite | on: Felienne Hermans: How patterns in variable names c...
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!!!
SnowHill9902 on May 22, 2022 | prev [–]
Agreed. When dealing with real values, it’s favorable to explicit the units: weight_lb, length_cm.
DonHopkins on May 22, 2022 | parent | next [–]
Yes, explicit unit suffixes are good smurfs!
Also: eschew Bill and Ted's Excellent Postfix "_not", which inverts the meaning of the variable name. That's a most totally bogus code smell, dude.
Could "Sam" even pull that stuff anymore with PR review processes? I would just comment on every variable name in the PR to "remove sams" or "make clearer".
And he loved to get "artistically creative" with "elegant variation" of variable names and naming conventions, permuting and mutating them at every level, and making up cute unique abbreviations by randomly dropping characters to save a few keystrokes of typing, then spicing it up with whimsical nonsense like "aardvark" and "pancake", instead of boringly predictable consistent correctly spelled descriptive big-endian names like I prefer. (He claimed that made it easy to grep the code.)
He would even alternate between CamelCase and lowerCamelCase and snake_case and Snake_That_Ate_A_Camel_Case and UPPER_CASE and runtogetherlowercase in the same fucking variable name, occasionally throwing in the random "sam_" and "_SAM" prefixes and suffixes for good measure!
He also liked hard wiring the path of his home directory into code, of course. He was like a territorially possessive dog pissing on all the trees and fire hydrants he could find, and all the code he wrote sucked.
That made it extremely hard to separate the "arteest" from their "work", and not to criticize the person as well as the code. But at least it was easy to tell at a glance which code needed to be tossed out and rewritten.
Please don't be a Sam! There are some people who do deserved to be criticized as much as their code.
Elegant Variation (which is a terrible idea despite its fancy sounding name):
https://en.wikipedia.org/wiki/Elegant_variation
>Elegant variation is a writer's substitution of "one word for another for the sake of variety". The term was introduced in 1906 by H. W. Fowler and F. G. Fowler in The King's English. In their meaning of the term, they focus particularly on instances when the word being avoided is a noun or its pronoun. Pronouns are themselves variations intended to avoid awkward repetition, and variations are so often necessary, that they should be used only when needed. The Fowlers recommend that "variations should take place only when there is some awkwardness, such as ambiguity or noticeable monotony, in the word avoided".
Big-Endian Naming Molds, Code Smells, Smurfing:
Felienne Hermans: How patterns in variable names can make code easier to read
https://www.youtube.com/watch?v=z7w2lKG8zWM
>Name molds let you structure variable names to maximize the chance of different programmers guessing the same name.
https://news.ycombinator.com/item?id=31472523
DonHopkins on May 22, 2022 | parent | context | favorite | on: Felienne Hermans: How patterns in variable names c...
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!!!
SnowHill9902 on May 22, 2022 | prev [–]
Agreed. When dealing with real values, it’s favorable to explicit the units: weight_lb, length_cm.
DonHopkins on May 22, 2022 | parent | next [–]
Yes, explicit unit suffixes are good smurfs!
Also: eschew Bill and Ted's Excellent Postfix "_not", which inverts the meaning of the variable name. That's a most totally bogus code smell, dude.