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

231–240 of 599 posts

Re: Goodbye, Clean Code

#231

Post by ummonk »

babarock wrote: post #114
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…

One of the areas where I really like "incidental duplication" is in tests. Tests can sometimes be very repetitive and identical, and it's tempting to want to refactor it in some clever way. That's almost never good. On top of the reasons laid out in parent comment, tests also function as unofficial documentation. I like having everything explicit in there, it makes them easier to read and understand.

If you try to abstract away tests, you often just end up re-implementing the same abstractions used in the actual code, and you can end up not catching unfounded assumptions that your abstraction is making in both the tests and the code. There is a scope for having test helpers / utils to make tests easier to write, but you should be minimalist with these.

Re: Goodbye, Clean Code

#232

Post by vgrafe »

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…

This is about ownership. I agree there's no need to be personally attached to your own code. I have no problem with someone taking ownership of my work (understand refactoring/abstracting the crap out of it for the sake of Engineering). But the one day that person leaves the team, you have no choice but deal with that person's mental model, as nice or convoluted it was while refactoring. I've had this experience in every team I've worked with...

Re: Goodbye, Clean Code

#233

Post by isaachier »

BeetleB wrote: post #84

The first thing I did when I read this was come to the HN comments and search for people complaining about DRY: https://news.ycombinator.com/item?id=22022599 https://news.ycombinator.com/item?id=22022842 https://news.ycombinator.com/item?id=22022896 https://news.ycombinator.com/item?id=22022836 The author of this piece was not engaging in a DRY activity even if he thought he was. He (perhaps unwittingly) admits to it…

The Pragmatic Programmer is pretty zealous about DRY. For instance, the authors describe how they inserted sample code snippets into the book using specialized scripts developed for that purpose. A simple copy paste wasn't good enough (see p. 100-101). Granted, they had wanted to make sure the code snippets were tested and updated as needed, but repeating code anywhere seems to be a bad practice according this definition.

Re: Goodbye, Clean Code

#234

Post by aurelianito »

My experience is that good programmers prefer extra abstraction and bad programmers prefer extra repetition. Given that we need to work with bad programmers, sometimes it makes sense to make things easier for them. But repetition is wrong and a source of bugs. Each time you give in and keep a repetition that you know it should not be there you are crippling yourself to make us programmers a commodity.

Re: Goodbye, Clean Code

#235

Post by christophilus »

blhack wrote: post #207
madeofpalk wrote: post #199

Earlier quoted context omitted.

It's a shorthand, and its similar to what HTML does. If you don't like the optional shorthand, don't use it? I don't understand how this is something exclusive to React, or something it specifically encourages.

Yeah you might be right, and it definitely possible this is common and I’m just weird for not liking it.

It’s common, but you’re not weird. I’ve done a lot of React and front end programming, and I hate this pattern, too.

Re: Goodbye, Clean Code

#236

Post by bagacrap »

preommr wrote: post #206

Clickbait title. This is a story about: 1) Changing someone else's code without discussing it with them. Seriously, wtf?! Even if the code is better maybe there are reasons the code is the way it is and the it's not worth making the changes for the overall progress of the business. 2) Misjudging the requirements. If those modules needed changes, then they should've been left alone. This story could've easily gone the…

And a story about not having a code review process prior to check-in. How is a team of developers ever going to work together if they all write code completely on their own with zero input from or approval by others? That's why style guides exist.

Re: Goodbye, Clean Code

#237

Post by bagacrap »

brabel wrote: post #135
BeetleB wrote: post #84

The first thing I did when I read this was come to the HN comments and search for people complaining about DRY: https://news.ycombinator.com/item?id=22022599 https://news.ycombinator.com/item?id=22022842 https://news.ycombinator.com/item?id=22022896 https://news.ycombinator.com/item?id=22022836 The author of this piece was not engaging in a DRY activity even if he thought he was. He (perhaps unwittingly) admits to it…

> DRY is about not repeating requirements in code. Exactly! A lot of developers, even experienced (and I would include the OP, even after his supposed lesson) seem to not get this: duplication is only bad when what is being duplicated MUST behave the same by definition (i.e. if you change one but not the other, the other would've become broken as its definition would still be the same as the changed one). Otherwise,…

Problem is, it's hard to tell the difference in advance. In this case, it only became apparent to OP some time down the line.

Re: Goodbye, Clean Code

#238

Post by jdmg94 »

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…

inversion of control

Re: Goodbye, Clean Code

#239

Post by dragonwriter »

thefifthsetpin wrote: post #186
leoc wrote: post #131

Earlier quoted context omitted.

Wasn't it the case that the requirements were the same at the time the code was written? TextBlock.resizeTopLeft(...) and Rectangle.resizeTopLeft(...) did the same thing for the same reason, not by coincidence. The issue was the possiblity (and eventually the reality) of future divergence.

The issue wasn't divergence. The issue was that there was no requirement that TextBlocks should behave like rectangles. It's very possible that DRY could apply even where divergence is expected. Suppose we had a requirement that "A user should not be able to resize a TextBlock if they are not allowed to read the text." At the outset, the read & resize permission logic might be identical & DRY is easy to apply. Nobody…

> The issue wasn't divergence. The issue was that there was no requirement that TextBlocks should behave like rectangles.

But they had the same current requirements. So, ideally, the implementation of the common behavior should have been shared but shared in a way which didn't tightly couple the two consumers with each other, so that it would be simple for either to stop using the shared code.

Re: Goodbye, Clean Code

#240

Post by latchkey »

celticmusic wrote: post #219
jt2190 wrote: post #103

Earlier quoted context omitted.

> 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. Changing one developers _working code_ after they’ve invested a significant amount of time into without discussing it with the team first it is to basically heap on a number of unwritten requirements and also decide that the sch…

So relevant. I had an experience this year where I was working with another developer. This guy would legit walk behind me rewriting everything I did. To put this into perspective, I've been doing this work for over 20 years this guy came out of a bootcamp last year. But it wasn't even that this guy was rewriting things, it's that he was constantly breaking things as a result. Imagine every fucking day you come in an…

You sound really angry about it and you've hung onto it for quite some time. A good friend of mine used to tell me 'who cares?' when I would rant on about things just like you just did. It is honestly startling to hear that in response to a rant. If you answer 'i care!', then that is exactly the problem.

Let it go, it isn't worth it. At the end of the day, I'd say this is your problem to work on. You didn't step back, slow down, forget about the code, and mentor the other developer well enough when you were there. That is kind of exactly what the OP is saying in his post.

(Side note: I've been you many many times and it only hurt me in my career. I actively work against it now and things have been much better.)

Post reply on HN