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

131–140 of 599 posts

Re: Goodbye, Clean Code

#131

Post by leoc »

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…

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.

Re: Goodbye, Clean Code

#132

Post by [deleted] »

wizzzzzy wrote: post #108

One place I've found this to be especially true is when writing CSS. I went through a phase years ago of trying to abstract any repeated styles into 'clever' oocss patterns but in the end it's often lead to a confusing mess, in part because of the nature of CSS. In the end I've found duplicated and verbose code to be so much easier to work with and maintain.

[deleted]

Re: Goodbye, Clean Code

#133

Post by codingmess »

He made a tradeoff that later on turned out to be wrong. I don't think that is a mistake, after all, it wasn't foreseeable at the time.

It could just as well have happened that some other requirement would have made the original solution even more impractical.

I think the only mistake here might be overthinking things (can't comment on changing other people's code, depends on company culture).

Apart from "cleanliness", what about developer happiness. If a more elegant solution makes you happy, why not go for it, at least every once in a while?

Re: Goodbye, Clean Code

#135

Post by brabel »

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, two similar or identical codes are NOT duplicated in a way that violates DRY, they are just coincidental - as they might become different later - so the "duplication" in this case must NOT be removed (but perhaps a smaller portion of the code might be duplication of definition, which should be then extracted and de-duplicated). It really isn't that hard.

Re: Goodbye, Clean Code

#136

Post by fzeroracer »

Jasper_ wrote: post #110
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…

If someone spends a week or two writing a patch and you come in and rewrite it in an evening, that, in and of itself, is telling me something: You think your teammate is a worse coder than you, given you were able to solve it with "cleaner" code. You assumed that your solution was better, without talking to the person who authored it to see if they did things that way for a reason. This could have been solved with a…

I've humbled and have been humbled before because sometimes what looks like an ugly, unclean solution is the correct solution. There might be weird edge cases in the system that you catch, but the person doing the rewriting doesn't see until they push the code out and it breaks something in an entirely different part of the codebase.

That's the biggest reason why you should always, always discuss those changes with your coworkers first instead of going cowboy on it.

Re: Goodbye, Clean Code

#138

Post by kelnos »

marcus_holmes wrote: post #116
arendtio wrote: post #90

Earlier quoted context omitted.

If someone else is looking for examples too, I found those: https://www.reddit.com/r/Zig/comments/99zlc9/exceptions_or_e...

I thought all of this until I got used to Go's error handling. There's a couple aspects to this: 1. After a while, the "if err != nil {" becomes a single statement in your mind, and you only notice it if it's different (like trapping things that should error with "if err == nil {"). In other words, it only feels verbose if you're not used to it. After a while, the regular rhythm of "statement, error check, statement,…

The downside I see with go's error handling is that you can forget to check. With rust, if the function being called returns Result, you have to deal with the error (even if dealing with it just means propagating it out). Missing error handling is such a common source of bugs that go really turns me off here.

Re: Goodbye, Clean Code

#139

Post by amatecha »

awb wrote: post #122
Jasper_ wrote: post #110

Earlier quoted context omitted.

If someone spends a week or two writing a patch and you come in and rewrite it in an evening, that, in and of itself, is telling me something: You think your teammate is a worse coder than you, given you were able to solve it with "cleaner" code. You assumed that your solution was better, without talking to the person who authored it to see if they did things that way for a reason. This could have been solved with a…

> If someone spends a week or two writing a patch and you come in and rewrite it in an evening, that, in and of itself, is telling me something: You think your teammate is a worse coder than you, given you were able to solve it with "cleaner" code. You assumed that your solution was better, without talking to the person who authored it to see if they did things that way for a reason. The time they spent developing th…

Yup, the upfront effort to come to an implementation is like 90% of the work. Refactoring existing code is a lot easier than juggling product, design and technical requirements into a functioning solution. All the moving parts are already there to look at.

Re: Goodbye, Clean Code

#140

Post by cle »

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…

The point isn't to stroke your teammates' egos. It's to find out why the code is written that way, and to build consensus around a different way of writing it. Consensus building is a great way to improve the cohesiveness of the team. It lets teammates operate with a set up implicit, shared assumptions, which means they can spend more time on business problems and less time on these kinds of discussions.

Generally, lone wolves worsen the team dynamics, because they reduce team cohesion.

Post reply on HN