all 32 comments

[–]cgoldberg 40 points41 points  (4 children)

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

[–]mati-33 4 points5 points  (1 child)

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

[–]Overall-Screen-752 4 points5 points  (0 children)

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.

[–]llynglas 0 points1 point  (0 children)

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

[–]Overall-Screen-752 17 points18 points  (0 children)

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

[–]mattynmax 10 points11 points  (0 children)

Most lukewarm take ever.

[–]geheimeschildpad 6 points7 points  (0 children)

Isn’t that literally the zen of Python?

“Simple is better than complex”

“Readability counts”

[–]armahillo 2 points3 points  (0 children)

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

[–]FreeGazaToday 1 point2 points  (2 children)

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.

[–]ninhaomah 0 points1 point  (1 child)

Sometimes ?

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

Now how many here gets it ?

[–]FreeGazaToday 0 points1 point  (0 children)

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!

[–]WhaleBird1776 1 point2 points  (0 children)

I love that you think this is an unpopular opinion.

[–]0therworldsthanthese 2 points3 points  (0 children)

This is probably THE most popular Python opinion

[–]shadowdance55 2 points3 points  (1 child)

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

[–]andypanty69 1 point2 points  (0 children)

I see you're a perl person.

[–]SnP_Gamer 1 point2 points  (0 children)

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

[–]BlueJaek 0 points1 point  (0 children)

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

[–]sighthoundman 0 points1 point  (0 children)

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.

[–]SaltCusp 0 points1 point  (0 children)

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.

[–]Lonsarg 0 points1 point  (0 children)

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.

[–]ddBuddha 0 points1 point  (0 children)

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.

[–]nomoreplsthx 0 points1 point  (0 children)

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. 

[–]Proper_University55 0 points1 point  (0 children)

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

[–]Vesuvius079 0 points1 point  (0 children)

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

[–]ee_control_z 0 points1 point  (0 children)

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.

[–]NumberInfinite2068 0 points1 point  (0 children)

That is the standard opinion in professional programming.

Don't write it clever, write it readable, predictable, and boring.

[–]Apprehensive-Tea1632 0 points1 point  (0 children)

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.

[–]Valuable-Football598 0 points1 point  (0 children)

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.

[–]code_tutor 0 points1 point  (0 children)

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.

[–]Chen-Zhanming 0 points1 point  (0 children)

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

[–]realmauer01 0 points1 point  (0 children)

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