Clever code is probably the worst code you could write (2023)

Post by ern » Tue, May 21, 2024, 11:32 PM UTC

dheera wrote: post #39

jawns wrote: post #2

Here's an old joke about the progression from junior to mid-level to senior developer: Junior dev: My code is simple, straightforward, and easy to understand. Mid-level dev: My code is clever, innovative, expressive, hyper-optimized, and ingenious. Senior dev: My code is simple, straightforward, and easy to understand. In software development, "clever" solutions are like poems. In the best poems, there are usually mu…

Reality: This is mostly because mid-level dev needs to justify their existence in order to not get laid off or PIP and is worried about losing their H1B and having to uproot their entire family in 60 days notice. Hyper-optimized, hard-to-read code that only they understand is one way to increase reliance on them while giving a reason that can be put into a promotion doc. Mid-level jobs are worried about maintaining t…

Post by lupire » Tue, May 21, 2024, 11:33 PM UTC

jraph wrote: post #43

quotemstr wrote: post #8

Earlier quoted context omitted.

One pet peeve of mine is people using std::for_each instead of a simple loop

Same in JS. I once worked with someone who would use [].forEach and didn't like for loops because functional good, iterative loops bad. It was essentially in the coding style of the project and the for version would be rejected in MRs. I don't miss this. IMHO [].forEach just essentially expresses the same thing as a regular for loop, although in a more verbose and convoluted way that is also likely very inefficient b…

Post by floxy » Tue, May 21, 2024, 11:34 PM UTC

a_t48 wrote: post #10

porphyra wrote: post #4

I also find that, in C++, int sum = 0; for (int i = 0; i is a lot easier to understand than return std::accumulate(x.begin(), x.end(), 0, [](int a, b) {return a + b;}); Yet, the latter is considered more correct and better, with static analysis like cppcheck telling you to use the latter. It does have many advantages, like no mutable variables lying around, but gee it is annoying to read.

We now have return std::reduce(x.begin(), x.end()); Which is a little cleaner and is even faster (compiler is free to do the additions in any order). https://en.cppreference.com/w/cpp/algorithm/reduce - it looks like even the `accumulate` example can be made simpler with `std::plus`. I prefer the `reduce` option for a number of reasons, but understand why someone might not.

    return accumulate(x.begin(), x.end(), 0);

Post by williamcotton » Tue, May 21, 2024, 11:36 PM UTC

porphyra wrote: post #4

I also find that, in C++, int sum = 0; for (int i = 0; i is a lot easier to understand than return std::accumulate(x.begin(), x.end(), 0, [](int a, b) {return a + b;}); Yet, the latter is considered more correct and better, with static analysis like cppcheck telling you to use the latter. It does have many advantages, like no mutable variables lying around, but gee it is annoying to read.

Post by stephc_int13 » Tue, May 21, 2024, 11:38 PM UTC