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

Goodbye, Clean Code

overreacted.io

Post reply on HN
Print view View original

221–230 of 599 posts

Re: Goodbye, Clean Code

#221

Post by cellularmitosis »

danabramov wrote: post #18
temac wrote: post #13

> A healthy engineering team is constantly building trust. Rewriting your teammate’s code without a discussion is a huge blow to your ability to effectively collaborate on a codebase together. I'm against the idea that people should be attached to "their" code (that is: the code they wrote). Now I also understand that humans that humans, but the priority should be to make them evolve toward more detachment from their…

I think there’s a balance. There’s a difference between gradually improving something, or improving it at some point later — and literally rewriting 100% of code someone has just landed over the night.

This actually happened to me, (and his rewrite didn’t even work!). Having witnessed this first-hand, I can say that the impact of the code change was absolutely dwarfed by the lost trust. Unsurprisingly, I would come to find out that this engineer had what I would call the opposite of soft skills, and the notion of a “this irks me so I rewrote your code” has become a giant red flag for me.

Re: Goodbye, Clean Code

#222

Post by SlowRobotAhead »

burlesona wrote: post #10

I’ve usually heard this phenomenon called “incidental duplication,” and it’s something I find myself teaching junior engineers about quite often. There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right? So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you ne…

> I encourage my devs to follow a rule of thumb: don’t extract repetitive code right away, try and build the feature you’re working on with the duplication in place first. Let the code go through a few evolutions and waves of change.

... alright buddy, I’m going to need you to remove your spyware on my computer!

I just did this last week with a CBOR message interpreter in C. I did it the long messy way, saw a bunch of repetition, “cleaned” it, changed the way the parser is called, changed some of the validator that runs after it... then did that entire process two more times as requirements changed.

I’m near certain you wrote that ABOUT me! ;)

Re: Goodbye, Clean Code

#223

Post by nikodunk »

RealDinosaur wrote: post #62
scarface74 wrote: post #25

Earlier quoted context omitted.

That can be boiled down to the “Rule of 3”. My CTO often asks me to implement a feature to do X and make it “generic enough to handle future use cases”. My answer is always the same - either give me at least three use cases now or I am going to make it work with this one use case. If we have another client that needs the feature in the future then we will revisit it. Of course, there are some features that we know in…

I think the catch all term for that is YAGNI.

What is YAGNI?

Re: Goodbye, Clean Code

#224

Post by michaelcampbell »

scarface74 wrote: post #25
burlesona wrote: post #10

I’ve usually heard this phenomenon called “incidental duplication,” and it’s something I find myself teaching junior engineers about quite often. There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right? So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you ne…

That can be boiled down to the “Rule of 3”. My CTO often asks me to implement a feature to do X and make it “generic enough to handle future use cases”. My answer is always the same - either give me at least three use cases now or I am going to make it work with this one use case. If we have another client that needs the feature in the future then we will revisit it. Of course, there are some features that we know in…

Write once, copy twice, refactor after 3.

Re: Goodbye, Clean Code

#225

Post by ummonk »

I really get annoyed by the lack of good tooling to deal with abstraction. I wish there were a way to view abstracted code with function calls (to some depth) inlined and macros applied. It would solve a lot of the difficulties with heavily abstracted code while preserving the advantages.

>Secondly, nothing is free. My code traded the ability to change requirements for reduced duplication, and it was not a good trade. For example, we later needed many special cases and behaviors for different handles on different shapes. My abstraction would have to become several times more convoluted to afford that, whereas with the original “messy” version such changes stayed easy as cake.

The opposite is also often true though. If the requirements had changed in a uniform way across the different shapes, then it would have been much easier to apply the modifications to the abstracted code. The trick is to have an idea of what kinds of modifications are likely in the future, and when you're not sure yet, avoid premature abstraction but ensure things aren't so ad hoc you'll have trouble abstracting in the future.

Re: Goodbye, Clean Code

#228

Post by [deleted] »

Impossible wrote: post #217
scarface74 wrote: post #25

Earlier quoted context omitted.

That can be boiled down to the “Rule of 3”. My CTO often asks me to implement a feature to do X and make it “generic enough to handle future use cases”. My answer is always the same - either give me at least three use cases now or I am going to make it work with this one use case. If we have another client that needs the feature in the future then we will revisit it. Of course, there are some features that we know in…

Future coding has lead to some of the most overcomplicated systems I've worked with. It's one of the reasons (among many) I quit my last job. I was constantly told code that had no use cases was "important to have" because "we needed it".

[deleted]

Re: Goodbye, Clean Code

#229

Post by lonelappde »

Mirioron wrote: post #198
burlesona wrote: post #10

I’ve usually heard this phenomenon called “incidental duplication,” and it’s something I find myself teaching junior engineers about quite often. There are a lot of situations where 3-5 lines of many methods follow basically the same pattern, and it can be aggravating to look at. “Don’t repeat yourself!” Right? So you try to extract that boilerplate into a method, and it’s fine until the very next change. Then you ne…

I wonder if we could have IDE features that will make #2 less likely. Eg marking some lines of code that they're similar to lines of code elsewhere. And if you then change it in one place the IDE will remind you about the others.

Relying on your IDE to maintain program semantics is terrible. IDE should help you write good code that you commit, not be a crutch for writing bad code.

Re: Goodbye, Clean Code

#230

Post by kunglao »

1. If you broke a code, don't generalise it as an inherent problem of clean code. Just find what exactly you did wrong. 2. If the only reason you refactored it was because you felt it's not clean, don't do it - that code doesn't look terrible to me anyway. 3. To do this kind of refactoring you need good test coverage. So, start there. This also makes sure that you understand the specs well enough to refactor. 4. Clean code is good. It's a skill to know what is good code and what is bad code, what is better code and what is worse code and when to give in on clean code and compromise. Practice it.
Post reply on HN