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

21–30 of 204 posts

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

#21

Post by lopatin »

Jagerbizzle wrote: post #17

I’ve been a C++ dev for a couple of decades and know my fair share of unreadable code. I’ve recently started learning Python and holy shit, it’s like you get accolades in this language for doing as much as possible in as few characters as possible. Guess I’m getting too old for these young whippersnappers.

If you think Python is like that, I advise you to never look at Ruby codebase.

But seriously, of course you can write Python one-liners or nested comprehensions, but I get the idea that it's not really Pythonic. They still want clear, iterative code. It's just more concise, but the idea is the same, but with less scrolling.

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

#22

Post by jbandela1 »

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 sorts of cleverness.

For loops are clever with different parts of the statement controlling and executing different parts of the loop.

Compare that with BASIC

A six year old child can understand:

    10 PRINT “Hello”
    20 GOTO 10
Going on to object oriented programming, dynamic dispatch and v-tables are clever. What you call and where you go to in your program are determined by the dynamic type of an object. This is very far from the simple BASIC GOTO

What difference does looking at it like this make.

First we don’t reject automatically reject new concepts just because they aren’t simple. While function calls are complex, they bring many benefits. In addition, this approach emphasizes the role of education to in taking useful concepts and making them familiar to a broader group of people.

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

#23

Post by sesuximo »

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.

Imo it doesn’t matter at all. Both are fine. Surely there are more pressing things out there to think about!

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

#24

Post by fr4nkr »

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, and the end result is usually... not pretty.

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

#25

Post by amanzi »

tehnub wrote: post #16

This is true, but in code reviews and such, it often boils down to familiarity above anything else, like someone preferring names = [] for record in records: names.append(record["name"]) to names = [record["name"] for record in records] Now, I might say something if I saw this: import operator names = list(map(operator.itemgetter("name"), records)) Seems a bit unidiomatic given that list comprehensions are in the lan…

Great example. My personal preference is the first one, but I put that down to me being inexperienced and not working in a professional development environment.

I've been using Ruff with most of the rules enabled, and they have a page for this scenario here: https://docs.astral.sh/ruff/rules/manual-list-comprehension/

Another one that trips me up is the ternary operator: https://docs.astral.sh/ruff/rules/if-else-block-instead-of-i... I prefer the longer, more verbose version, even though the suggestion looks more clever.

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

#27

Post by hleszek »

tehnub wrote: post #16

This is true, but in code reviews and such, it often boils down to familiarity above anything else, like someone preferring names = [] for record in records: names.append(record["name"]) to names = [record["name"] for record in records] Now, I might say something if I saw this: import operator names = list(map(operator.itemgetter("name"), records)) Seems a bit unidiomatic given that list comprehensions are in the lan…

A simple list comprehension is quite readable and better IMHO. It is very common and most people will understand directly what it does.

Of course, when you have multiple levels or complex lambdas inside, then I agree that the for loop might be preferable.

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

#28

Post by haolez »

porphyra wrote: post #15
haolez wrote: post #7

Earlier quoted context omitted.

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.

using namespace std; is considered kinda bad since you don't want your namespace to be polluted with a bunch of std stuff. For example if you have `int count` lying around somewhere you'd want to be able to call `std::count` without fear of it being shadowed.

But ambiguity gives you readability. And if a "count" variable clashes with the function name, it's trivial for the compiler to catch this and warn you.

It's a matter of preference, but I'd still risk ambiguity and name collision, especially when you go beyond std:: (like boost stuff).

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

#29

Post by j1elo »

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.

Look at that link:

  2,4,6) ...
  These overloads participate in overload resolution only if
  std::is_execution_policy_v> is true.
  std::is_execution_policy_v> is true.
std::is_execution_policy_v? std::decay_t? std::remove_cvref_t?

Really, this madness with C++ needs to stop. People who work on newer versions of the language might be very conservative with the language syntax itself, but they clearly decided having carte blanche to adding an infinite amount of stuff to the standard library.

Could someone please force them to stop, somehow? The whole rest of the industry would be thankful.

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

#30

Post by a_t48 »

autoexecbat wrote: post #20
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.

I think most people would be thinking "hmm now I need to read what 'reduce' mean in this context"

For at least the first time, yeah.
Post reply on HN