To be clear, you don’t mean code golf levels of code-shortening, right? E.g. they’re also not sacrificing on clarity and readability of code to shorten it. They’re just removing unnecessary work. I think this is definitely good and creates a net gain for other devs.
Because the people who shorten code at the cost of clarity are some of my least favorite people. I once saw “half = num >> 1” instead of, say, “half = floor(num / 2)”. The latter is 100% more clear to more people and doesn’t gate-keep on engineers who haven’t memorized bitwise operators. (Also, this wasn’t a context where the bitwise operator would be optimized by the compiler in case they wanted to throw that hogwash out there.)
I think the accepted standard for "code length" is about the number of tokens used, not the number of characters (or at least should be). So no points for replacing readable identifiers with random punctuation or one character variable names. And comments don't count towards the length either! :)
> I once saw “half = num >> 1” instead of, say, “half = floor(num / 2)”.
Again, that's just stuff that's getting you a small constant factor less code, a few characters here and there. To get closer to an order of magnitude smaller program solving the same problem requires a deeper understanding of the problem and different strategies for solving it.
To me, the gold standard example for the 10x to 100x coder is always Peter Norvig.
Notice the clear comments and detailed explanations and reasonable identifier names. But do you think the median developer would solve these problems with a similar amount of actual code?
Was standard practice and understandable by most engineers, as well as far and away much faster than a divide.
Now-a-days, using a compiled language they are going to be translated into the same machine code supporting your point. However, it might still be a good idea in a scripting language doing heavy math lifting.
But personally, short, standard, and sweet is preferable to crazy newfangled mental model. I've seen way too many real-world examples of the idiom "it takes a lot of skill to write Java in every language."
Because the people who shorten code at the cost of clarity are some of my least favorite people. I once saw “half = num >> 1” instead of, say, “half = floor(num / 2)”. The latter is 100% more clear to more people and doesn’t gate-keep on engineers who haven’t memorized bitwise operators. (Also, this wasn’t a context where the bitwise operator would be optimized by the compiler in case they wanted to throw that hogwash out there.)