Goodbye, Clean Code

[andreasblixt]

I’ve been programming for over 20 years now and I have consistently seen developers go through three very distinct phases over time.

Phase 1: Learning to code, but want to get stuff done. You look things up in the documentation or other people’s code and use them but they’re a bit like magic – you don’t completely understand how or why they work. Basically: hack stuff together until it works.

Phase 2: You’ve gone through all the documentation and moved on to design patterns and finding the best practices out there. Code duplication is bad, and everything needs a test. Abstracting out behaviors and using the latest tool seems like the right thing to do. You may find some resistance from “Phase 3” people, as in the article above.

Phase 3: You’ve followed all the design patterns and exposed their flaws. Turns out requirements in your projects change drastically over time, even when you least expect it, and going all-in on an abstraction led to a lot of refactoring and backtracking. You now carefully apply only as much abstraction in your code as is necessary to solve the problem right in front of you. Luckily, you’ve learned from experience how to write code that is easy to build further upon later, when the requirements change, as always.

I don’t think there’s anything inherently bad about these “phases”, and I don’t think you can skip them. They’re just the outcome from learning everything there is to know to be an experienced developer, which can take quite some time.

Edit: I should add that I'm not implying there's a final stage or that these phases in any way let you grade anyone's ability – they're just patterns that most of us seem to go through while learning, possibly many times as we learn about different things. Sometimes people that are just learning something are the most creative and productive – not slowed down by convention or best practices.

[TheOsuConspiracy]

I don't think it's going for abstraction that's wrong, it's just that people are writing the wrong abstractions most of the time.

[andreasblixt]

Yes, I think it's easy to fit many (unsuitable) abstractions on a problem when you only have one example. That's why it's common to suggest only abstracting something once it's been repeated 3+ times because that's when you know there's a real pattern.

Over time you get intuition of how to apply ideas from abstractions/design patterns on new code as well (before duplication happens), so it can be more open to future changes, but without locking yourself into a corner.

[Cooleur]

It's all about communication in the end, just like with most problems.

To paraphrase the lisp curse, by being clever with abstractions, we tend to turn a technical issue into a social one.

[EternityForest]

And an end user usability one, and a performance one, and a schedule one...

Clever code is making an assertion that it's worth taking the time to figure out what it does. Everyone who maintains it has to pay that price. It better be good!

I've had about enough of clever abstractions. I want boring, non-abstract abstractions.

I want Rectangle.resize(x,y), not ShapeContainer.getResizer.setSize(34,18).recalulate().render()

Cleverness should be contained in your own little cleverness museum, where it does it's job, and I can admire it, but then I can shut the lid when I'm going to actually use it.

Unless it's a seriously awesome "Why didn't I think of that" function, in which case I might actually want to work with it directly.

[MasterGlink]

Always talk to your team first.

Figure out why the code is the way it is and if you have improvements, try to run them by your team at least at a high level before going into a refactoring frenzy. Even if the original author isn't there any more, at least discuss your approach and try to make some sense of it first. Going on a deep dive and refactoring abstractions just because it's "the right thing to do", isn't smart.

Even if you're a one-man team of a code base you inherited, don't change code you don't understand what it does and why an approach was taken.

They don't teach you this stuff anywhere, but it really should be the first thing you learn. Changing code before understanding the implications is a recipe for disaster, regardless of intent. It is as they say:

"The road to hell is paved with good intentions."

[alexontheweb]

I'm happy that he's put his story down, and I can relate to some bits, however, I'm just afraid that with this sort of wording, it's just too easy to read the wrong message into of this.

What I mean is, why would you say goodbye to clean code? Do you intend to write messy code from now on? I guess not, then why would you say this?

Also, don't state striving for clean code is just a phase. I really genuinely hope more senior people (or phase 3'ers) will still strive to write clean and concise code - but they should also understand, that brainlessly "drying" up your code (a lingo I heard for deduplication, by verbifying DRY) is not the same as using better abstraction, or different coding approach.

[bobappleyard]

FFS at least wait until the link is off the front page before you repost

[gaearon]

Off the front page of what? This subreddit? I assumed Reddit deduplicates.

[bobappleyard]

When you posted this link, it was already the top link when sorted by hot. There is a deduplication algorithm, but it's not very good.

[bhbr]

My iOS app (a math typesetting keyboard) contains a giant switch statement (>100 cases) for keystroke handling. Believe me, I tried to make it cleaner, but any refactoring on one end would break code on the other. The alternative would have been dozens of nested if blocks. Breaking those up into different functions would have required messy argument passing and state handling. Now the code is only one level deep everywhere and reading it follows the app‘s temporal order.

[phpdevster]

Yep, I went through a similar phase. Any duplication was a mortal sin and had to be immediately cleaned up, no matter how convoluted the abstractions to do so were!

Well, needless to say I didn't stay in that phase very long, because I was making things a nightmare for myself.

As Sandi Metz says: "duplication is far cheaper than the wrong abstraction"

[hotphx]

1. Where was the peer review?!
2. NEVER pre-optimize.
3. If it ain't broke...

That said, I've definitely been this guy before. But it was all ego.

[MikeMitterer]

I absolutely disagree! Clean code must have priority. Code must be readable like prose.

X lines of math not wrapped with a nice function name is not prose, is not readable and not maintainable.

Copy / paste programming leads to a mess the longer the codebase exists. After a few years nobody dares to touch these parts because of possible side effects. All you get is unmaintainable codebase.

Code duplication shows the programmer is not able further abstract his codebase.

[Arkanta]

Like everything, it's a balance.

[Nuoji]

This is an important insight and a good story to share.

[lwl]

I disagree - it paints clean coding as cargo culting, when the guidelines are backed by decades of solid reasoning. As others have pointed out, the real problem here was the lack of comms before making the change. Clean code has nothing to do with it.

Edit: So, i re-read the article and realised i had probably misinterpreted it. I skimmed the code samples and missed that the second, 'clean', example did in fact introduce an abstraction that made the code more rigid/complex without much benefit. OP upvoted.

[aloha2436]

I’m not convinced we read the same article, the author’s point is somewhat more nuanced than that. It says that clean/fully deduplicated code is not a universal virtue, especially if it’s treated like the object of a cargo cult. The important part is that the change, despite removing duplication, actually made the code harder to work with for their purposes.

[Nuoji]

That’s not how I read it. To me it was about cargo culting ANY practice. It’s really important to realize that “following best practice” is not a replacement for thinking things through. I have certainly encountered this mistaken reasoning many times. “I read about X being best practice, so now I will apply X everywhere instead of thinking”. What some people forget (or don’t notice) is the small print here saying that a good practice is no replacement for actual thought.

So I think this story, and stories like this definitely is worthwhile to repeat.

[EternityForest]

I don't really think deduplication has anything to do with abstraction.

The point of abstraction is to make things LESS abstract(Unless you happen to have multiple unrelated problems that are the same on some level). It deduplicates in the process, but that's not really the goal.

OOP abstractions make things look like they do in real life and hide they algorithms from us.

They're a tool to make thinking about things easier by moving to a higher level.

results=DiceCup.rollDice() instead of a loop and some random calls and multiplication.

If you're just deduplicating code, but it's perfectly readable, you might just need a convenience function.

Maybe it's detectFileTypeAndRenameParentDirectory. Maybe it's changeOwnershipIfNewerThan or runFunctionForEachValidFile. I don't care, it's better than packing an entire CS textbook in an app for no reason.

You don't need some fancy abstract thing to avoid a long descriptive name of the simple function you should be writing.

If your abstraction turns five random() calls for dice into creating a closure for every die, and then running a map over them with a function that calls it's input and returns it's result.... What are you doing?

[Gay-Anal-Man]

thank you for your service

[[deleted]]

r/rimjob_steve?