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

91–100 of 599 posts

Re: Goodbye, Clean Code

#91

Post by daxfohl »

This reminds me of Wayne Gretzky's phrase "Skate to where the puck is going".

A really good coder will find clever ways to implement the requirements in the most DRY fashion possible. And it will be perfect. Until the next requirement comes along. This is skating to where the puck is.

At some point you pick up the knack to know where to just leave things dumb and obvious as possible, because something inside you is shouting that there's going to be some new requirement soon that breaks the abstraction you're considering.

Re: Goodbye, Clean Code

#92

Post by pytester »

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.

YAGNI is about not adding functionality until it's needed. DRYing code isn't adding functionality.

Re: Goodbye, Clean Code

#93

Post by harry8 »

Controversial:

Is this the same disease that leads to the love of Haskell by those particular zealots (more not all Haskell programmers) who write yet another monad tutorial to spread the word of the one truth without writing any useful programs? Seeing "ah this is sequencing, so i can abstract that..." And so on. Haskell gets you to higher and higher levels of abstraction in your programming but doesn't seem to guarantee you'll get a useful program at the end of it.

(Yes there are useful Haskell programs, obviously. Just less of them than monad tutorials by at least an order of magnitude)

Re: Goodbye, Clean Code

#94

Post by skipants »

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…

Agreed. And more importantly, (2) is waaaaaay easier to fix than the problem you outlined in your preamble.

Re: Goodbye, Clean Code

#95

Post by Ace17 »

whoisjuan wrote: post #60

If there's something that I have learned about refactoring code that is repetitive into "cleaner" shorter code, is that the refactored version looks better but it's way harder to understand. When other people try to look at the "cleaner" version they have to spend more time trying to understand it and mentally untangle the abstraction. I like syntactically shortcode as long as it's clear. I also understand that somet…

> When other people try to look at the "cleaner" version they have to spend more time trying to understand it and mentally untangle the abstraction.

If you have to do this, either your abstraction is "wrong" (e.g leaky) ; or perhaps your identifiers are inappropriate?

(As a rule of thumb: not being able to figure out a good name is a sign that the abstraction might be misplaced.)

Re: Goodbye, Clean Code

#96

Post by Hendrikto »

lilyball wrote: post #73
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 have 2 rules I use when determining whether to duplicate code or to refactor: 1. How many duplications are there? If the code is duplicated once, that's fine. If it's duplicated twice (so 3 instances of it), then it's time to consider refactoring, subject to the next rule. 2. Why is the code duplicated? If it's "incidental duplication", i.e. code that happens to look the same, don't refactor. Only refactor if there…

> attempt to predict the future

Sounds very error prone…

Re: Goodbye, Clean Code

#97

Post by dpc_pw »

whoisjuan wrote: post #60

If there's something that I have learned about refactoring code that is repetitive into "cleaner" shorter code, is that the refactored version looks better but it's way harder to understand. When other people try to look at the "cleaner" version they have to spend more time trying to understand it and mentally untangle the abstraction. I like syntactically shortcode as long as it's clear. I also understand that somet…

On the other hand duplication is harder to review. If you have 20 lines of

    x1 * y[i] + z2
    x2 * y[i] + z3
    ...
or other dense math code, then it takes a lot of effort to spot any tiny mistake.

Duplication vs abstraction is a very context dependent subject, and with many subtleties, one often no best answers.

Re: Goodbye, Clean Code

#98

Post by danabramov »

monksy wrote: post #85

To me this sounds like he gave up on producing something with craftsmanship. It sounds like he's getting bullied by someone of lessor experience. If the code was blainently duplicated, that's going to create problems later.

I think saying repetition makes code worse is like saying repetition makes prose worse. Both code and prose convey ideas. Repetition is a tool. You can overuse it, and you can underuse it. But it is a tool. Not a flaw.

Re: Goodbye, Clean Code

#99

Post by kirstenbirgit »

It's tiring to work with developers who have a very narrow focus on "correctness" and e.g. code style. It can result in a lot of extra work, extra refactoring, extra cleanup, extra rewrites, etc.

It's how you end up with a toolchain, build environment and release process that's worthy of Netflix, but you're just 5 developers, and it takes up all your time to maintain.

Always focus on how it's benefiting the business. Is my time better spent on something my customers need or want, than fixing something that's already working?

Re: Goodbye, Clean Code

#100

Post by fyp »

Why must the messy code win in this case?

Building a transform tool should be a pretty well understood problem. Just take a look at what photoshop's transform tool does and you will see all the possible extensions you might need to support in the future (rotate, skew, distort, perspective, warp, transform origins, a bajillion modifier hotkeys, etc).

Of course don't go ham and support all of them up front. But with those future use cases in mind, it's pretty hard to write yourself into a corner. I would say Dan's refactoring looks fine other than needing more customization for positioning and handle behavior. But it seems easy enough to just add them later.

Post reply on HN