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

201–210 of 599 posts

Re: Goodbye, Clean Code

#201

Post by detaro »

blhack wrote: post #195
madeofpalk wrote: post #194

Earlier quoted context omitted.

What are some examples of React's focus on shorthand and abstraction? React is fairly small and doesn't really encourage much at all. The one 'battle' that I often find myself in is "should this be a seperate component?" but that's more of a people problem and something that every language and framework will have.

Instead of writing It’s just Of course there might be some completely valid reason for this, but it’s baffling to me why you would want this type of shorthand, instead of just explicitly writing what you mean. Of course in golang this could be something like: var someVariable //is false someFunction(someVariable) But I would (personally) not write code like this if I could avoid it. It would be: someVariable := false…

it mirrors HTML syntax: https://html.spec.whatwg.org/multipage/common-microsyntaxes....

Re: Goodbye, Clean Code

#202

Post by buzzkillington »

fzeroracer wrote: post #181
buzzkillington wrote: post #161

Earlier quoted context omitted.

Or have tests. If your push comes with tests and I reduce the code by half while still passing all of them it means that 1). you didn't actually test everything you've done 2). you didn't write code as well as you should have 3). I'm an idiot and made the code less robust. 1) happens all the time. 2) happens some of the time 3). happens as often as 2.

This seems more like a post-hoc justification than any real rationale for change. There's nothing stopping your new code from introducing new testing requirements that weren't needed for the original code and it sounds like for 1) it could be equally a case of you blaming another developer when its actually 3) that occurred. This also assumes that everything is actually testable, sometimes you write unclean code beca…

If the other dev can't be bothered to document why they did something anywhere they should be fired.

Re: Goodbye, Clean Code

#203

Post by sojournerc »

chubot wrote: post #192
dboreham wrote: post #155

Earlier quoted context omitted.

Tests frequently have bugs, especially bugs that result in the test passing when it should fail.

That’s why I make the test fail before writing the code. If the code is already written, then I break it in the minimal way to test the test, and then fix it.

IME things never fail in the way you expect them to... You can build a fortification where you think you are weak only to find the enemy is already in the castle.

Re: Goodbye, Clean Code

#204

Post by Jasper_ »

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…

The same gut reaction that causes you to go "ugh, crap code, I'm going to rewrite" is probably similar for the other developer, but with your rewritten version.

People tend to have an aversion to code they didn't write in general, and actually reading and understanding existing code tends to be a rare skill.

> Also, rewriting something is far easier than writing it from scratch.

Given the amount of times I see companies rewrite their product with half the features missing and more bugs than before, I'm not sure I agree with that.

Re: Goodbye, Clean Code

#205

Post by yodsanklai »

zmmmmm wrote: post #169
yodsanklai wrote: post #38

Earlier quoted context omitted.

> Then you need to start passing options and configuration into your helper method... and before long your helper method is extremely difficult to reason about In which case, you should split the helper function ( extract sub-part common to all cases, and report the differences where the helper function is called). I think I would most of the time go with de-duplicating as early as possible, as long as the helper fun…

> Duplicated code causes many issues. You mentioned introducing bugs, but it also makes the code harder to read That is I believe contestable. Yes, it can end up easier to read but there is a big tradeoff - when you remove code from its context it is much harder for a reader to reason about it. Once something is extracted into a function you can't see, you have to mentally ask the questions like "could this return nu…

Ideally, these questions should be answered by the function name, type, and its documentation. And if not, one can always jump to the function definition and the above elements (missing if the piece of code is inlined) will give additional hints to what the code does.

Re: Goodbye, Clean Code

#206

Post by preommr »

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 other way with the author competently abstracting away messy details for an overall positive impact. This happens quite frequently, but obviously doesn't make for a good article because it's expected.

Re: Goodbye, Clean Code

#207

Post by blhack »

madeofpalk wrote: post #199
blhack wrote: post #195

Earlier quoted context omitted.

Instead of writing It’s just Of course there might be some completely valid reason for this, but it’s baffling to me why you would want this type of shorthand, instead of just explicitly writing what you mean. Of course in golang this could be something like: var someVariable //is false someFunction(someVariable) But I would (personally) not write code like this if I could avoid it. It would be: someVariable := false…

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.

Re: Goodbye, Clean Code

#208

Post by JamesBarney »

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 ask myself a couple of questions to decide when to abstract code to de duplicate it.

1. Is this domain logic or plumbing code?(for instance would this logic be described in a spec for the application)

2. How many times will these be duplicated?

3. How abstractable is it?

3.a. to abstract it will I have to do anything tricky like pass functions around use reflection?

3.b If I abstract this logic into a function is there a good concise name for it?

Re: Goodbye, Clean Code

#209

Post by lonelappde »

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.

Terrible acronym for a good idea: DAMP

stackoverflow.com/questions/6453235/what-does-damp-not-dry-mean-when-talking-about-unit-tests

Re: Goodbye, Clean Code

#210

Post by shkkmo »

jrumbut wrote: post #164
lilyball wrote: post #73

Earlier quoted context omitted.

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…

It's also useful to look at not just the duplication but the code itself. In this case, it was code for geometry which is not like to change all too much. Often the difference between harmless but ugly looking duplication and duplication that is actually harmful relies on the semantics of the code and not just its appearance.

It wasn't code for geometry, it was code for manipulating geometric shapes via UI. the article specifically mentions that custom behavior was eventually needed:

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

Post reply on HN