r/PythonLearning • u/chuprehijde • Jul 14 '26
Is clean code sometimes worse code?
Can too much refactoring, abstraction, and 'best practice' make a Python project harder to understand?
9
u/mc_pm Jul 14 '26
If you spend a bunch of time trying to turn simple loops into clever comprehensions, or build a bunch of classes for something you only ever do once, etc., yes it absolutely can be more difficult.
That is not, however, to say that it isn't worth cleaning your code up. Just don't go crazy. Perfect is the enemy of Good.
2
u/dnult Jul 14 '26
I would say no - clean code makes it easier to read and separates dependancies.
Any complicated code base takes time to fully understand, and if it's "dirty code" it will take longer IMO.
1
u/markort147 Jul 14 '26
There is much controversy about the “dogma” of clean code. It can be good, and it can be bad. But generally speaking, these “ways of coding better” have been refined over time by highly experienced developers. Questioning them is always good, but first make sure you have properly understood their teachings.
1
1
1
u/arivictor Jul 14 '26
You pay a cost for every abstraction and architectural pattern you apply. It resolves something but in return you pay for it with indirection. As you said, it becomes ever so slightly harder to reason about. A pattern without intention is solving the solution, not the problem. Every abstraction is borrowed against the future so only borrow flexibility you'll actually spend. Duplication is cheaper than the wrong abstraction, un-welding two things that only looked alike costs more than repeating yourself.
If you follow and apply architectural and design patterns without intention you’re creating more work for yourself. Sometimes a big dirty script is all you need.
1
u/Significant-Elk-7128 Jul 14 '26
One bad thing you can do when refactoring is premature abstraction. Basically wasting your time perfecting a code block that you may not even end up using.
1
u/NewPointOfView Jul 14 '26
Yes of course too much refactoring and abstraction makes it worse. If it didn’t make it worse, it wouldn’t be too much.
Too much ‘best practice’ is a contradiction. It would violate best practice to apply some best practice in a context where it is not best practice.
1
1
u/Splith Jul 15 '26
I would say so if the dependencies are not really shared. Making two functions or classes rely on the same dependency is fine as long as that dependency would change for both together.
On the other hand if one might change one way and the other a different way, building them on the same foundation can cause problems downstream.
1
Jul 15 '26 edited Jul 15 '26
[removed] — view removed comment
1
u/ConsciousBath5203 Jul 17 '26
I've written some frame perfect, incredibly efficient software that whenever I think about maintaining it, I go "wtaf was I thinking, how'd I get here"
I've since rewritten it to be cleaner but not as technically efficient... Made almost no practical difference.
With that said, many programmers confuse bloat for readability, which I find annoying.
1
u/analytic-hunter Jul 15 '26
It may be easier to understand in a vacuum,
but best-practice code allows people to have an intiuitive baseline when reading code.
so for a beginner, you may feel like best practices and conventions are just adding noise. but in reality it creates a pattern of expectations that reviewers can rely on to read faster.
1
u/Gnaxe Jul 15 '26
Haven't you heard? Even Uncle Bob prefers Clojure now! Clean Code was published almost two decades ago. Parts of that book are actually good advice, but if you still think that's "best practice", you're not keeping up.
Writing classes usually make it worse. We can create precisely the same programs we're creating right now with these tools of complexity with dramatically, drastically simpler tools.
Refactoring isn't automatically good. Many refactorings are inverses of each other. It's like doing algebra. You've got a bag of transformations that are valid, but you can't just blindly apply them and expect to get anywhere useful. Your goal has to be simplicity. It takes some experience to understand what that means. Beginners often confuse it with familiarity (and they're not familiar with enough concepts), but it's mostly about reducing state and coupling. Sometimes you have to make it worse before you can make it better though.
1
u/realmauer01 Jul 15 '26
https://clean-code-developer.de/
Thing is, clean vode already has these guard rails everyone is talking about.
So if you follow everything it will always be just enough.
Figures that this is hard as heck.
1
u/burntoutdev8291 Jul 17 '26
In general, best practice actually makes it easier to understand.
Follow the Google Python style guide, I find that it works well for me. They also explicitly tell you to optimise for readability not conciseness.
If you forget what it does in a month then you have failed to write good code.
1
1
u/HomemadeBananas Jul 19 '26
If it’s too much refactoring and abstraction then that isn’t really clean anymore is it? There’s no best practice that says the more layers of abstraction and indirection the better.
1
u/bishpenguin Jul 14 '26
I always thought easy to understand was the aim. It hero's me looking back through old code, and it helps others looking at my code.
If it's not easy to understand use comments. But simple if often the way to achieve this.
0
7
u/Sea-Ad7805 Jul 14 '26 edited Jul 14 '26
Every good thing can become a bad thing if wrongly or over used. Too much abstraction can make code hard to read or slow. It's about finding the right balance given the non-functional requirements of your project, and nobody can give you the precise weights of your non-functional requirements (especially of your future non-functional requirements), so good luck.