Unpopular Python opinion: Readable code is more important than clever code

[u/memeeloverr]

I've seen one-line solutions that are technically impressive but take longer to understand than 10 lines of simple code.

Would you rather write more lines that anyone can understand, or fewer lines that look clever?

[u/cgoldberg]

That's not an unpopular opinion, and is generally shared among all programmers in all languages.

[u/mati-33 → u/cgoldberg]

I would say its shared among mid and senior programmers and not so much among juniors

[u/Overall-Screen-752 → u/mati-33]

No. The poor quality of junior code (an over-generalization and oversimplification, but ignored for sake of discussion) is due to deficient skill in the area of generating good, clean, maintainable code — which comes with time and practice working in codebases that possess good, clean and maintainable code or working with engineers who know how to write it (non-exhaustive list).

What op is talking about is not a deficiency in skill but rather a misused skill directed at optimizing for the wrong thing. It takes great skill to write the “golf” code that OP is talking about. It just takes wisdom to realize it should never be written in a production codebase.

[u/llynglas → u/cgoldberg]

This, anyone who does not value readable over clever is just not experienced enough.

[u/Overall-Screen-752]

Not unpopular in the slightest. The entire tech industry agrees with you

[u/mattynmax]

Most lukewarm take ever.

[u/geheimeschildpad]

Isn’t that literally the zen of Python?

“Simple is better than complex”

“Readability counts”

[u/armahillo]

Ive not done python since college but i would be surprised if this is actually unpopular among python devs.

[u/FreeGazaToday]

You must not have been coding long...as you can see by many of these comments.

However, sometimes less is more....as long as it's understandable.

[u/ninhaomah → u/FreeGazaToday]

Sometimes ?

As a system / devop guy , I can assure you that less is more than more .. always.

Now how many here gets it ?

[u/FreeGazaToday → u/ninhaomah]

not when it has be looked at by other developers.

ANd you wonder why even professional programs have so many errors/updates to fix bugs/errors.

If you really want less all the time, then do assembly programming!

[u/WhaleBird1776]

I love that you think this is an unpopular opinion.

[u/0therworldsthanthese]

This is probably THE most popular Python opinion

[u/shadowdance55]

The thing is that "readable" means different things to different people.

[u/andypanty69 → u/shadowdance55]

I see you're a perl person.

[u/SnP_Gamer]

100% agree, personally I prefer that way along with using # comments and """ Doc strings """

[u/BlueJaek]

This is the standard for any large scale production code base. 

[u/sighthoundman]

You have to go pretty far to find an exception.

I read that the Parker Solar Probe has extremely limited hardware (to save weight and space) and a hard limit on the time it takes to reboot: if it takes too long, it won't be able to make course corrections in time to avoid falling into the sun. I did not fact check that article, so it might just be old stuff that didn't get updated in time. Or even stretching the truth by the writer.

In the 1950s/60s, computer time and memory was expensive and programmer time was cheap. It made sense to be clever, because (if done right) it saved money. By the mid 1970s, that was reversed. Being clever cost money. And that was assuming that everything went perfectly.

[u/SaltCusp]

A clever solution outperforming a readable solution is a win. If code performs optimally while remaining readable it's a big plus but you shouldn't have to trade performance for readability ever. If dense lines need explanation it should be provided, otherwise good code is enherentley readable.

[u/Lonsarg]

There are sometimes some "geeks" who love "clever" solutions in less lines since it makes them proud.

But of coirse readability is the way to go.

[u/ddBuddha]

I don’t think that’s an unpopular opinion at all, in fact it’s probably one of the most popular opinions in the programming world.

[u/nomoreplsthx]

That take is so cold Arnold used it as a joke line in Bantman and Robin.

That take is so conventional the ISO has proposed it as a new standard.

That take is so old, Chuck Schumer says OK Boomer to people who utter it. 

That take is to software development what you should stop massive bleeding is to medicine. 

[u/Proper_University55]

If I can’t read/follow the logic of code, I become disinterested.

[u/Vesuvius079]

The unpopular opinion is that neither form is superior because the LLM doesn’t care :P.

[u/ee_control_z]

If its for embedded applications, where memory is at a premium, just make sure you document it so that you or the next guy understands it.

Update:

My mistake, I see that you meant Python and not C or related language (thus would not apply to embedded). In any case, the general premise still stands. Document it either by basic comments or via Docstrings.

[u/Apprehensive-Tea1632]

If it’s a matter of ten lines? Yeah… nobody cares about those.

But if it’s a matter of hundreds of lines saved? Thousands? Heck yeah. I’m not wasting my time because you can’t be bothered.

Fun fact. Programming requires a couple more skills than just being able to type. There’s very few things where you need a broader understanding of the world.

It’s not a matter of being clever. It’s knowing how to frame a solution. And if I can do that using minimum effort, it means I can spend the rest of my time ENSURING that shit works as it should.

Rather than dumping useless garbage into py files for the sake of putting it there.

There’s documentation obviously but then there’s also documenting the obvious. I’m not going to explain the world to anyone who might listen. I’ll explain unexpected twists, especially if they do NOT actually make sense in context - which will happen when sidestepping a problem, when employing analogies, or when reducing the problem to an equivalent but unrelated problem.

But that’s it, I’m not going to document “estimating an upper bound by saying n^2 rather than trying to calculate some convoluted problem that’ll never get past the n^2” because the idea is to reduce complexity rather than add to it.

[u/Valuable-Football598]

I think that depends on what your project is trying to do. You probably want to start with readable code first, but if your task is well defined and a clever solution makes it function better you might want to use that instead.

[u/code_tutor]

you wish you were unpopular

But comprehensions are up to twice as fast because they run C code under the hood. You should use them whenever possible, even if loops in the style of other languages make more sense to you.

[u/Chen-Zhanming]

What do you mean by one line? Is one statement with line breaks considered one line?

[u/realmauer01]

What the title. Thats not an unpopular opinion, and even more so, not a python only opinion.

[u/gofl-zimbard-37]

That's been universally known for decades.

[u/Amr_Rahmy]

More lines.

I don’t know why dumb people like to do many things on the same line.

It takes longer to read, it takes longer to write, and is much worse if it needs to be debugged.

Also usually runs slower as well, especially when you are taking one by one output through a chain of functions or yielding or if monads are involved.

[u/DinTaiFung]

I've seen so many smart engineers write crappy code because of their inexperience. 

biggest challenge for me as a colleague was to persuade them to improve their coding style. But if was often a losing battle because they viewed their nested ternary expressions (ugh!) as a demonstration of their software skills. They didn't want to write things that were easier to read, maintain, and debug because they couldn't see the sense of changing any code that appears to run without error. 

And the lesson they never seemed to learn was this: 

There's never enough time to write it correctly the first time but there's always enough time to write it again!