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

11–20 of 599 posts

Re: Goodbye, Clean Code

#11

Post by detaro »

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…

And in the other direction, when adding flags etc to a method that was created to reduce duplication, consider if splitting it into two "duplicate" copies or copy it to the call-site requiring the flag isn't the better alternative.

Re: Goodbye, Clean Code

#12

Post by danabramov »

BelleOfTheBall wrote: post #7
rckclmbr wrote: post #5

Earlier quoted context omitted.

A good post about someone learning that writing code is more than just about how pretty it looks. How you work with others is incredibly important in this industry

Is that not common knowledge? I feel like this is a well-written post with a good point but it's a familiar point. You could boil part of it down to 'all's good in moderation', so don't just keep your code clean, keep it clean and easy to read, etc.

I didn’t mean to imply there’s anything novel in my post :-) someone’s gotta beat that drum once in a while.

Re: Goodbye, Clean Code

#13

Post by temac »

> 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 work and acceptance that what they design "can" (actually will) be imperfect, rather than avoiding upsetting them even when it would not be justified to be upset. Plus one essential purpose of source control is to be able to make changes, and revert them if they were "wrong"; or for any other purpose. Maybe propose a patch instead of committing directly, but that's really a cultural matter about how projects are organized.

I don't want to ask of permission for an improvement. If there is a need to have formal authorization of maintainers responsible for parts of the code, they setup just that. Otherwise, I'm certainly going to improve "your" code, in some rare cases without even telling you (that's not a goal in itself to do it behind your back, obviously, and I also value collaboration -- but that should not be a problem). The question that remains is: is it really an improvement. If you are not sure, then maybe don't commit. If you are, do it (following your local rules), and if it ends up being a mistake, yes, it will be reverted, and so what?

You should not take issue of your work being reverted (for good reasons), like other people should not take issue of "their" code being modified. Better ask for forgiveness than permission.

> 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.

Then re-expand the code later.

Re: Goodbye, Clean Code

#15

Post by erik_seaberg »

boffinism wrote: post #9

I think this highlights an important nuance to the Don't Repeat Yourself maxim. It's not just about whether two bits of code are similar now. It's about whether, when they change in future, they are likely to change in the same ways. If not, then DRYing up the code now is only making more work for yourself down the line.

I've always found the https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle, where you derive from classes instead of editing them in-place, sort of appealing for this reason.

Re: Goodbye, Clean Code

#16

Post by danabramov »

detaro wrote: post #11
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…

And in the other direction, when adding flags etc to a method that was created to reduce duplication, consider if splitting it into two "duplicate" copies or copy it to the call-site requiring the flag isn't the better alternative.

Yes. If extracting and deduplicating is in your toolbox, so should be inlining and duplicating.

Re: Goodbye, Clean Code

#18

Post by danabramov »

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.

Re: Goodbye, Clean Code

#20

Post by rubatuga »

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 mean, it's nice to talk about ideals, but it's also highly unrealistic that people are able to separate the code they write and what is says about them. Especially if you are part of a newly formed team, you must make sure that there is trust, respect, and clear communication, because this is the stage where most misconceptions occur. Upon building a successful foundation, you can test new team dynamics such as changes in communication that tradeoff that initial safety for more efficiency.
Post reply on HN