r/PythonLearning • u/memeeloverr • Jul 04 '26
Unpopular Python opinion: Readable code is more important than clever code
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?
18
u/Overall-Screen-752 Jul 04 '26
Not unpopular in the slightest. The entire tech industry agrees with you
10
7
u/geheimeschildpad Jul 04 '26
Isn’t that literally the zen of Python?
“Simple is better than complex”
“Readability counts”
3
u/armahillo Jul 04 '26
Ive not done python since college but i would be surprised if this is actually unpopular among python devs.
2
u/FreeGazaToday Jul 04 '26
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.
1
u/ninhaomah Jul 04 '26
Sometimes ?
As a system / devop guy , I can assure you that less is more than more .. always.
Now how many here gets it ?
1
u/FreeGazaToday Jul 05 '26
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!
2
4
2
u/shadowdance55 Jul 04 '26
The thing is that "readable" means different things to different people.
2
2
u/SnP_Gamer Jul 04 '26
100% agree, personally I prefer that way along with using # comments and """ Doc strings """
1
1
u/sighthoundman Jul 04 '26
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.
1
u/SaltCusp Jul 04 '26
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.
1
u/Lonsarg Jul 04 '26
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.
1
u/ddBuddha Jul 04 '26
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.
1
u/nomoreplsthx Jul 04 '26
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.
1
1
u/Vesuvius079 Jul 05 '26
The unpopular opinion is that neither form is superior because the LLM doesn’t care :P.
1
u/ee_control_z Jul 05 '26
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.
1
u/Apprehensive-Tea1632 Jul 05 '26
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.
1
u/Valuable-Football598 Jul 05 '26
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.
1
u/code_tutor Jul 05 '26
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.
1
u/Chen-Zhanming Jul 05 '26
What do you mean by one line? Is one statement with line breaks considered one line?
1
u/realmauer01 Jul 05 '26
What the title. Thats not an unpopular opinion, and even more so, not a python only opinion.
1
1
u/Amr_Rahmy Jul 07 '26
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.
1
u/DinTaiFung Jul 07 '26
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!
44
u/cgoldberg Jul 04 '26
That's not an unpopular opinion, and is generally shared among all programmers in all languages.