As much as i like the concept in general in life, in this case its just "you are not your lines of code".
Also people who criticize people make a mistake kind of.
Always criticize the code, not the person.
Also people who criticize people make a mistake kind of.
Always criticize the code, not the person.
Now sure it depends on the type of criticism in question. Finding a bug or other practical problems obviously isn't, but talking shit about a way something is arbitrarily set up that the author thought was really neat would absolutely be.
This line of thinking also reminds me of how every time some actor or director or whatever is implicated in some scandal, their work is also tainted forever instead of being taken at face value for what it is. Can we separate the artist from their art? Is it even possible? I doubt it.
Code is made to be efficient in a compagny, it's not "personal" or here to make you have feelings. So if you can't discuss efficiency because you'll hurt people it's just bad. If you do art, you create art with respect to your own sensibility emotions so yeah be weary of criticizing someone's art.
There's always external influence, but if you're involved you obviously added something and in most cases it can be scrutinized on its own merits.
As much effort and ego you put in it, it will still suck in some way.
You wrote some bad code. You are not a bad code writer.
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.