Live data from Hacker News

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

read.engineerscodex.com

141–150 of 204 posts

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

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

the readability issue here is in part that function arguments are purely positional in c++.

a little over the top for this simple example, but you can always create local variables to document intention.

  auto initVal = 0;
  auto accumulateOp = [](int a, b) {return a + b;};
  return std::accumulate(x.begin(), x.end(), initVal, accumulateOp);
I'd prefer to see a for each loop over algorithms functions in such simple cases, but I'd prefer almost anything over direct indexing when it isn't necessary. when I see that in new code, my first thought is always "what am I missing here?".

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

#142
> Clever code is probably the worst code you could write

But you should write it anyways. Preferably in a situation of little consequence (school, personal projects, prototyping, etc...)

Otherwise, how do you make the difference between code that is simple and code that is just dumb?

"not clever" code typically has: copy-pasting, no abstractions, hardcoded values, global variables, cascading "if"s... And sometimes, it is the right thing to do, but good, readable code is usually a bit more clever than that.

But how do you know the right kind of cleverness? For me, the best way is to experiment. Sometimes, trying to be clever fails, sometimes, it really makes your code better, but if you don't try, your code will never get better.

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

#143
post #10

Earlier quoted context omitted.

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.

> and is even faster (compiler is free to do the additions in any order) Is that actually true? I'm not even sure how hypothetically removing ordering requirements would help you extract performance, let alone any compilers that could do anything with that today. Unless the standard library were to auto-parallelize the reduction, but I doubt they'd do that because the overhead of starting threads would be quite costl…

The linked page has benchmarks - I'd have to go dig into godbolt to see why it's faster. The standard library can actually auto-parallelize, but you have to opt in (see the ExecutionPolicy argument).

Edit: I don't know how to dig into the actual implementation of std::reduce on godbolt - it's not inlined. I think the sibling comment has it right though - one can do adds of four at a time with whatever SIMD extensions are available.

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

#145

Earlier quoted context omitted.

What would qualify as clever Python? These kind of broad and vague statements make me wonder if I am guilty..

For a simple example, I think the walrus operator (:=) could be considered clever. I like it, and use it, but the fact that you can declare a variable, store a value in it, and then perform actions depending on its value, all in one line, gives me pause. if (foo := bar()) is not None: baz(foo) Whereas the traditionally accepted Python method of dealing with this would be EAFP: try: foo = bar() baz(foo) except Attribu…

In your first example I think most people would skip the 'is not None' as None is already falsy and drop the extra braces.

I find it visually clearer than the second example where the cause and effect are slightly separated, but I do agree there's an element of cleverness to it.

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

#146
post #102

I think “clever” is more related to unfamiliarity. There is actually a lot of cleverness going on that people just become familiar with. Structured programming is actually very clever if you think about it. Function calls are, when you look at it closely, very clever. It encapsulates how to jump to a function entry point, how to pass on values in registers or in memory, how to adjust stack pointers, and all other sor…

It's not this and there is a test: Judging something assumes at least a minimal level of expertise in both the domain and language. I don't know Ruby, a lot looks obtuse, that's not a sign of clever code. If I see examples like the article in languages I know, it's 'clever code'.

But even then, there's degrees of knowledge and familiarity within that. For example, in Python, is using the `else` block of a for-loop clever? It's a part of the language that I'm familiar with - in principle it's just domain knowledge. But I've worked with plenty of Python devs who've never seen or used that construct before. For them, it's often black magic, and a classic example of "clever" code.

The point is that everyone judges cleverness based on what they know and are familiar with. If I need to think too hard to understand it, then it's clever code. But everyone has different levels of familiarity and experience, which means that cleverness is always an individual metric.

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

#147
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've seen junior devs write code carefully, putting time and effort into it. The code was ornate and almost too over-commented.

mid-level devs become more pragmatic, but can skimp on both elegance and simplicity vs complication.

What's interesting is that decent senior dev code sometimes almost looks careless, but really works well in the end. For example, immediately exiting with an error instead of complex error recovery. (the latter would just move the problem around and make finding and fixing the root cause more troublesome)

Another thing would be duplicating code instead of doing some complex re-use with complicated conditionals.

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

#148

Earlier quoted context omitted.

I don't think it's accurate, though. Junior devs often write overly complicated code because they don't really understand the problem they're trying to solve. Junior devs write unintentionally complex code, mid-level devs write intentionally complex code, senior devs write simple code.

Sometimes seniour devs write complex code but hide the complexity behind a simple interface.

I'd include this as table stakes for a senior dev. You don't always need to work on complex code, but I'd expect they work to go to a senior dev and I'd expect complexity to be hidden behind a simple interface.

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

#149
post #65

Earlier quoted context omitted.

>the `accumulate` example can be made simpler with `std::plus` Accumulate, surprisingly enough, accumulates by default: return accumulate(x.begin(), x.end(), 0);

Just make sure you're accumulating integers and not doubles!

Obviously, you have to use

   std::accumulate(v.cbegin(), v.cend(), decltype(*v.cbegin()){});
:) :) :)

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

#150
post #68

Everyone thinks they're writing good code. Even many experienced seniors write code that they think is good code but others loathe. Best case, they can at least solve problems without introducing new ones; though more often than not, they're still making many junior mistakes while couching them in senior terminology. Aside: Do we really need to keep rewording this exact same essay every month since the first computer…

Hey if no one is writing blogspam and posting it to HN, when am I gonna get to drop my hot take on what differentiates junior, mid, and senior developers? And what about my thesis that there is actually a huge difference between programmers, developers, and engineers? My identity is really wound up in all of this so it's important that I get an opportunity to put other developers down.
Post reply on HN