Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

read.engineerscodex.com

Post reply on HN
Print view View original

101–110 of 204 posts

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

#101

Post by bsza »

Xeoncross wrote: post #14
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.

int sum = 0; for (int i = 0; i Pretty much looks the same in all C-like languages. I've written that in Java, Go, TypeScript, PHP, etc... On the other hand, that second 'clever' example always looks different for every stupid language. It's std::accumulate in C++, streams in Java, list comprehension in python, etc... Clear is better than clever.

> Pretty much looks the same in all C-like languages

Because it’s ancient; that doesn’t necessarily make it better or clearer. Look at it like you’ve never seen it before. It has an entire line of boilerplate smack bang in the middle. Sure, your brain filters it out because you’re used to it, but it’s still fugly. And it’s prone to typos/copypaste errors like all boilerplate.

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

#102

Post by mianos »

jbandela1 wrote: post #22

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

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

#103

Post by Tao3300 »

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…

Best summarized in meme format:

https://x.com/nice_byte/status/1466940940229046273

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

#104

Post by bluGill »

TheCoelacanth wrote: post #80
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…

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.

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

#105

Post by gregjor »

I suppose every generation of programmers has to rediscover this and it can’t hurt to keep writing articles and books about it.

From The Elements Of Programming Style , 1978, by Kernighan and Plauger, rule one: “Write clearly – don't be too clever.”

The whole book, a short read, spells out principles and wisdom from experience that all programmers would benefit from.

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

#106

Post by f33d5173 »

sgarland wrote: post #13
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.

That is somewhat annoying, yes. I'm a huge fan of Python's list comprehension, but it's generally accepted to be a normal part of the language, and IMO, more readable: print([x for x in range(10) if not x % 2]) [0, 2, 4, 6, 8] vs. l = [] for x in range(10): if not x % 2: l.append(x) print(l) [0, 2, 4, 6, 8]

I've seen people complain about wrapping a comprehension over multiple lines, but I can't imagine packing them all in one. In your example, I would spread it out over five lines, so it would be at as long as the imperative case.

While I like python, I think the unusual order that components of a comprehension are written is to its detriment. It would make more sense if they were in the same order in both examples. The python ternary has a similar issue.

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

#107

Post by o11c »

lupire wrote: post #32
a_t48 wrote: 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.

That's terrible! The main operation, addition, is completely hidden magic! But the completely trivial calls to .begin() and .end() are explicit! Why would I want to add by default?

std::ranges::fold_left (since C++23) can take a range directly instead of a separated pair of iterators, and requires the explicit add.

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

#108

Post by RangerScience »

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…

Mostly, yeah - although

Good poems give you clear meaning now, and deep meaning later.

I think probably great code is like that, too. It’s clear in how it addresses the immediate needs, but it’s deep in how it sets up addressing later, subtler, or less proximal needs.

Git itself comes to mind. At the basic level, it’s super straightforward: you have diffs, you put them in a row, that’s a branch. Easy. Clear.

Then you want to do something weird, and lo and behold, you can. The “cleverness” - maybe call it the “clever simplicity” - that it’s built out of makes it possible, and “easy”. The deep part of the poem, that you didn’t need to understand in the beginning, starts becoming apparent and meaningful.

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

#109

Post by dijksterhuis »

morkalork wrote: post #57
fr4nkr wrote: post #24

I would argue that what constitutes clever code varies a lot by language. There's always a "cleverness" threshold where being able to read or refactor the code becomes harder, but this threshold isn't universal. Python in particular makes it very easy to be too clever, since its extremely rigid syntax was designed specifically to discourage it, but it ended up giving the user the necessary tools to be clever anyway,…

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

TL;DR

- OOP obsession is a common python developer phase. it's a dangerous phase.

- maintainable code is not minified code. minified code is minified code.

- stoopid code is often stoopid enough when it satisfies real world / human concerns, not technical concerns.

----

I've done all of these, and I see other people repeating them.

1. hyper optimised and utterly fragile class based inheritance / abstractions. Not optimised in performance. Optimised in terms of minimisation of code. avoid ABCs like the plague. YAGNI so save yourself some heartache and keep it stoopid.

2. especially when ^ includes many static methods that could be standalone functions. a good sign the code can probably refactor to functional + objects/dataclasses (and probably be easier to test as a result). You didn't need it, go back to keeping it stoopid.

3. methods that call another method, that calls another method, that eventually calls one of the static methods. often when I see this, none of these child methods are called by anything else. someone wrote multiple separate methods because apparently we shouldn't write methods with more than 10 LoC. because that's how to write clean code apparently. just put it all in a single method so I don't have open multiple different browser tabs while sitting in the doctor's office responding to an incident on my phone. stop optimising for LoC and make it obviously stoopid.

4. hiding how the code will run away from main entrypoint by adding a `className.run()` method. yeah, cool, your main function has been minified. kudos. But now I have no idea what steps your script will run. I have to go and read something else. make it obviously stoopid to someone reading this for the first time.

5. using names of concepts from other languages. don't call classes an "Interface" or a "Controller" because it sounds better. This isn't Java nor is it Kubernetes. It's python. keep names so stoopid that I can understand when my phone has woken me up at 3 am.

6. functional is usually simpler, until you start turning in a mathematician. you are not a mathematician. and neither is the junior sitting next to you. don't overuse recursion or currying etc. keep it stoopid enough that the junior sitting next to you has a chance of taking over responsibility for it one day without going through a PhD in mathematics.

7. avoid using functionality from the last 3x minor versions of python [0]. slow down and let others catch up first so we can all be stoopid together.

----

caveat: experience will vary wildly between different hoomans regarding what is considered stoopid enough.

[0]: a good exception here is something like case matching. this was pretty big so I would have allowed that, so long as everyone was aware it was a new thing now (I'd have done a post on slack saying -- Oi, go look at this, it's big)

Post reply on HN