Hacker News Reader

Comment by ttoinou | Hacker News Reader

We still need a way to track that there’s some common pattern in the code. So that when we update one pattern we wonder about the others places in code with the same pattern. Avoiding duplication doesn’t solve that

View on HN

My metric for that is "does that code MEAN the same thing" or "does it just look the same". Has worked quite well for me so far. I frequently find myself making a copy of some code rather than adding a parameter (most commonly done with code that would get some flag added)

Me too ! I don't follow DRY that much, I'm aware that copy pasting is good enough for a few weeks / months to see how things evolve in the future, and do refactor when it's really needed. That said, how do you know if they mean different things ? For GUI code for example, they do mean the same thing, but there's a good chance the code will evolve in the future so premature refactor are wasted time

GUI code changes as fast as your GUI does. If you have two buttons, call makeButton twice. If they have totally different sizes, don't calculate the size inside makeButton. If tomorrow you want a button and a checkbox, don't call makeButton twice with isCheckbox=true the second time.

Fun fact: Win32 checkboxes are buttons with a bitflag that says they are actually checkboxes.

Mostly by looking at the calling site where the code is already used and the calling site where I want to reuse it. If both of those mean the same (calculate the tax on x products, for the purpose of applying to the shopping cart, vs for applying to generating reports) then I'll reuse it, if it can be achieved without adding stuff like flags, in most cases. In other cases, it just looks the same (sum some field + calculate a percentage of that, for example, for discounts vs taxes on products) where it's obvious that they don't mean the same. (Though, I do heavily rely on a good type system to deal with future evolutions of that copied code)

TL;DR: Vibes

Its always about how far ahead in the future you plan ahead. And sometimes this future thinking is wasted time

This right here.

Here we're loading the customer record and updating their discount %

Here we're loading the broker record and updating their commision %

They will have 99% identical code.

It's possible but exceedingly unlikely we have found 2 things that should be a load_record_and_update_percent(file,id,field,val)

Tomorrow the business logic behind one of those will no longer be a simple % and now you have a real mess.

Why a mess?

> when we update one pattern we wonder about the others places in code with the same pattern. Avoiding duplication doesn’t solve that

It can, that's all about how aggressively you factor and structure your code, eg. combinators make it easy to reuse code in different application patterns without rewriting.

In which language do you use combinators for that ?

Even in that case the refactor can introduce mental overhead when having too many different variable / properties names

Any language that I can write a combinator in. It's quite easy in C, for example.

Reply on news.ycombinator.com