Live data from Hacker News

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

read.engineerscodex.com

1–10 of 204 posts

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

#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 multiple layers of meaning, nuances and subtleties, some harder to tease out than others. Sometimes you have to sit with a poem for a while before you are able to truly drink it all in. To mid-level engineers, writing this sort of poetic code has an intoxicating appeal. It allows them to flaunt their talents, demonstrate their mastery of the language, and impress their colleagues with their ingenuity.

But more often than not, what is really needed is the code version of ordinary prose: straightforward, with a preference for clarity over succinctness, easy for others to understand, easy to edit, and with fewer surprises and deviations from convention than a poem. With prose, particular the sort of no-nonsense style found in wire news reports and explanatory journalism, the best work is easy for the reader to comprehend and lends itself to being edited. For instance, a skilled copy editor can condense it to fit, if need be.

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

#3
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…

I just say, bell curve meme

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

#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.

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

#7
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.

I like C++, but I don't understand this tradition of keeping these annoying namespaces prefixed to everything. Just get rid of those std::, foo::bar::whatever::, etc from your code and make it more readable. Use the "use" clause. It's very rare for such names to be ambiguous in the same file, unless I'm missing some bigger picture here.

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

#8
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.

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

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

#10
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.
Post reply on HN