Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Goodbye, Clean Code (2020)

overreacted.io

Post reply on HN
Print view View original

111–120 of 224 posts

Re: Goodbye, Clean Code (2020)

#111

Post by brainwipe »

I think articles like this serve to drive absolutism through clickbait title. "Goodbye clean code" becomes "It’s an attempt to make some sense out of the immense complexity of systems we’re dealing with". And on the other side you have people writing "Comments are evil, burn die" and in the text you have "Comments shouldn't repeat the code, but are necessary sometimes, use your brain".

In the real world of real people coding and not in click-bait land, people use clean code as a tool that's sometimes appropriate.

Re: Goodbye, Clean Code (2020)

#112

Post by SamuelAdams »

makecheck wrote: post #95

I used to be much more of a curmudgeon about wanting to clean up existing code on sight but a few bits of reality seeped in over time, such as: 0. Existing code is probably working fine, and making changes (for any reason) risks adding a bug. Worse, reviewing code with a bunch of reformatting is tedious and the reviewer may assume you’ve only done reformatting and not notice the accidentally-changed behavior either.…

4. It increases personal liability and risk if something goes wrong due to a refactor.

I’ve worked at “blame game” companies before, if your name was on the commit it was your fault, all other process steps be damned.

So it reduced my inventive to change things unless actually required to ship a feature or fix.

Re: Goodbye, Clean Code (2020)

#114

Post by prerok »

It's weird that the author agrees with their sentiment. In my opinion, duplicating code is never the right answer.

Using a different form of deduplicating would be the solution here. Just write a few functions that do the math and then call them, rather than create new abstractions that can later become monstrosities. I think they learned the wrong lesson here.

Just my two cents :)

Re: Goodbye, Clean Code (2020)

#116

Post by dgb23 »

gpderetta wrote: post #31
LennyWhiteJr wrote: post #23

"first you learn the value of abstraction, then you learn the cost of abstraction, then you're ready to engineer" - Kent Beck

Premature abstraction is the root of all evil.

I liked this article about "semantic compression"[0] by Casey Muratori very much. He also posted some video lectures fairly recently about what he calls "non pessimisation" (a term that I personally didn't read anywhere else so far), which is mostly concerned with performance, but the idea is to simply avoid and isolate abstraction and indirection and programming in a style that adheres to what some people describe as mechanical sympathy.

It basically comes down to:

1. Write the code that makes the computer do what it needs to do to achieve a specific goal. No more and no less.

2. Refactor ("compress") the code by deriving re-used (implicit) structures and functions.

He puts a lot of emphasis on those steps being done in order and on deferring the second step

Note that this is from someone who writes games/engines/tooling so there is a large, real pressure to write simple and reasonably performant, optimizable code. He would also prefer that most of programming would be done in this way.

[0] https://caseymuratori.com/blog_0015

Re: Goodbye, Clean Code (2020)

#117

Post by sombremesa »

gchamonlive wrote: post #85
pelasaco wrote: post #80

I'm shocked that from all discussion nobody noted the root of all evil: "It was already late at night (I got carried away). I checked in my refactoring to master and went to bed, proud of how I untangled my colleague’s messy code." No PR, no code review, no CI. Just a cowboy pushing to the master..

And using clean code wrong. Clean code is not a panacea. If people use it as such and without the correct agile rites, they should do it at their own peril, but blaming it on clean code is at the very least naive (and somewhat dishonest)

Personally, I disagree that DRY is the same as “clean”. Clean code is merely code that has been thoughtfully structured (regardless of repetition) and is relatively transparent as to its purpose.

Re: Goodbye, Clean Code (2020)

#118

Post by vletal »

sombremesa wrote: post #110
V-2 wrote: post #13

"Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it." While undeniably true, this feels completely orthogonal to the question of clean code. You could ruffle someone's feathers in the exact same way by taking code into the opposite direction. "Goodbye, Clean Co…

HN has a lot of people who seem to benefit from these types of “common sense” articles that bury the lede, judging by the fact they appear on the front page so frequently. (Putting common sense in scare quotes to acknowledge that this is new information to some, no matter how obvious to others)

Is it really the case? Could it maybe be that these clickbeity titles are upvoted and comment on more, regardless of the questionable added value to the community "burried" deep inside?

Re: Goodbye, Clean Code (2020)

#119

Post by emaginniss »

lowercased wrote: post #61
shikoba wrote: post #14

Earlier quoted context omitted.

Why one should ask to the original developer if the code can be modified? If I see a code I want to change, I do it. I don't ask for permission. And colleagues can do the same with code I wrote. We trust each other.

Years ago (2005?) I worked at a call center. Most agents were on one coast - data center was in another coast. Agents in our call center complained about speed. When they'd pull up an account, it was taking seconds... sometimes 15-20 seconds... to pull up the account. This was all a bespoke CRM system. I poked in the code (it was something I had access to) and noticed that ... the entirety of the whole screen was dup…

A lot of people attach their ego to the work that they produce. I did when I was younger and would try and defend poor choices because I had made them. They were my children. Once I put that aside and separated my ego from my code, I got much more comfortable pointing to my own mistakes and learning from them. I am a far better engineer and teammate because of that.

Re: Goodbye, Clean Code (2020)

#120

Post by Spivak »

danuker wrote: post #41
VBprogrammer wrote: post #34

Earlier quoted context omitted.

The thing I hate most is when some creates the "new way of doing things". Then fails to convert most of the existing code which is "doing things the old way" even when it's clear that it is the same thing.

The "new way of doing things" is risky and might not turn out so good after all. If you treat the new way as an experiment, and only gradually convert the rest of the code, you're in for a smoother ride.

Please no, this is how you end up with 20 different experiments and zero consistency in everything. Gradual migrations are fine because it makes project managers happy but it requires a commitment to actually follow through with it. If there's a chance that you won't actually have dev time to finish the migration then just don't do it. It can't be that important then.

It's totally fine to try out an experiment in a branch and deploy to QA but don't deploy it to prod until you're sure.

Post reply on HN