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

471–480 of 599 posts

Re: Goodbye, Clean Code

#471

Post by seattle_spring »

luord wrote: post #470

> Let clean code guide you. Then let it go. Nah, no offense to the react fans but I'd rather listen to Fowler than to this guy. Sure, there are very specific exceptions where repeated code is an asset instead of a liability (and many of them are, appropriately enough, when dealing with graphics), but they are that: very specific . For 99% of situations, we ought to follow the principles (obligatory IMO).

Do you have specific experience that suggests that hyper-generalizing code before you even know about multiple use cases is beneficial over carefully extracting shared logic only when needed?

If I to pick one single practice junior engineers employ that ultimately bites everyone in the ass, it's a blind adherence to generic code and DRY at all costs.

Re: Goodbye, Clean Code

#472

Post by _pmf_ »

kqr wrote: post #321
teh_klev wrote: post #196

Earlier quoted context omitted.

> don’t extract repetitive code right away, try and build the feature you’re working on with the duplication in place first. Let the code go through a few evolutions and waves of change. This ^^^. I'm in my mid 50's now and worked as a software dev since my teens. I've learned over time that certain lumps of code need to be left alone for a while before jumping in and aggressively refactoring the perceived "duplicati…

> As an apropos to the article, and touched upon therein, checking in a fairly major change to de-duplicate some code without consulting the original author/team is a wee bit rude. This sounds like the outcome of bad culture. Ownership of the code should be shared to the point where it should never be considered rude to improve the code. Any part of the code. > Ask your colleagues first why such code still exists bef…

> This sounds like the outcome of bad culture.

For 90% of shops outside the cornucopia of SV with unlimited budgets and internal customers only, the client drives decision mercilessly and ruthlessly.

Re: Goodbye, Clean Code

#473

Post by _pmf_ »

b0rsuk wrote: post #389
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…

From my experience, I would start with a more compact implementation first in hopes that it would save me time . This usually ends with me having to do more complicated operations in my head to plan the code. It's tempting. It's like trying to do math in your head to save time - often leads to a mistake. Now I believe there's no shame in trying out a solution first and rewriting it later when I get a feel what the pr…

> The only downside of later optimization is that in commercial environment they often don't let you clean up.

Exactly (speaking for custom industrial automation projects). The follow up next requirements for a project might be in 5 or 7 years or never. You would be cleaning up a 80% dead project. In these environments, it's not uncommon to no longer have a dev environment because the system is a singular testbench that costs upwards of 2 million and only exists in 2 factories, so all bugfixes must be extremely conservative and any refactoring is stricly forbidden because there's no way to locally test for regressions.

Re: Goodbye, Clean Code

#474

Post by wool_gather »

bjourne wrote: post #462
JoeyJoJoJr wrote: post #406

Earlier quoted context omitted.

This reminds me when a developer took over my codebase while I was on holiday. When I returned I had discovered that he converted all tab indents to spaces across the entire project. He completely destroyed my ability to perform diffs against earlier commits, because his preference was evidentially more important. Of course this was all justified with a link to Google’s coding style guide.

The commonality in both your and the parent's situation is that you reacted defensively. Your response was "You destroyed my tabs!" when a proper response would have been to try and understand your coworkers motivation. Perhaps he had some really good arguments for preferring spaces over tabs? Tabs can be problematic in heterogeneous environments where developers with different tab settings and different editors work…

Frankly, the justification doesn't matter here: A change of that scope should be discussed and agreed on with teammates before you even put up a patch, not committed while the primary developer is out of town.

Re: Goodbye, Clean Code

#475

Post by jhoutromundo »

lmm wrote: post #416
altitudinous wrote: post #244

I'm 52 many would consider my code a mess. Been a professional coder -> solution architect all my life, I work for me now with my own apps. With my own code I clean things up when I can, but sometimes it isn't worth it. I used to write clean code, spend time doing it but no more. - Rewriting requires retest, introduces new bugs. - If it ain't broke, don't fix it. - Users don't care about clean code. They only care ab…

> - If your code requires constant maintenance you are doing it wrong. Disagree. Your code should reflect the business you're in, and changes to the business are what creates opportunity and let you turn your skills into profit. Clean code is absolutely a means to an end, and if you've got a codebase that's just sitting there fulfilling some static business purpose then yes, it makes sense to leave it ugly. (Similarl…

I think implementing new features isn't the same as maintence. Maintennce is to make something that isn't working work.

Re: Goodbye, Clean Code

#476

Post by _pmf_ »

luord wrote: post #470

> Let clean code guide you. Then let it go. Nah, no offense to the react fans but I'd rather listen to Fowler than to this guy. Sure, there are very specific exceptions where repeated code is an asset instead of a liability (and many of them are, appropriately enough, when dealing with graphics), but they are that: very specific . For 99% of situations, we ought to follow the principles (obligatory IMO).

I think you're confusing Fowler and Uncle Bob.

Re: Goodbye, Clean Code

#478

Post by tsukurimashou »

woutr_be wrote: post #373
bjourne wrote: post #274

> Firstly, I didn’t talk to the person who wrote it. I rewrote the code and checked it in without their input. Even if it was an improvement (which I don’t believe anymore), this is a terrible way to go about it. 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 totally disagr…

I need to disagree with you, I've been in a few positions where one engineer suddenly decided to rewrite parts of the code base without any input from other engineers. It's a huge blow to team morale, and it gave me a fear of writing code in this team. Every time I wrote a piece of code, I wondered how long it would be there for, I understand that code evolves, but seeing your code being rewritten after a week is no…

I know that programmers are humans but I think paying too much attention to people's feeling is what is dragging the IT industry down, if you have self esteem issues go see a shrink

Re: Goodbye, Clean Code

#479

Post by DataWorker »

abrax3141 wrote: post #456
endgame wrote: post #248

Earlier quoted context omitted.

From (I think) an old Joshua Bloch talk on API design, paraphrased: * If you generalise based on one example, you will get a flexible API that can handle only that example. * If you generalise based on two examples, you will get a flexible API that can switch between those two examples. * If you generalise based on three examples, you have a chance of abstracting over the common essence.

Hmm. I wonder if he got that from Simon while he (JB) was at CMU. He (HS) once said to me, jokingly, I think, “One makes an observation, two makes a generalization, three makes a proof”.

Sounds good but is wrong. Sometimes you need more than 3. Maybe 3 is for those who need to move fast and break things though.

Re: Goodbye, Clean Code

#480

Post by erikpukinskis »

beaker52 wrote: post #428

I dislike the panning of "clean code" in the article because I really think that duplication can be clean as shown. Clean code has a quality of comprehension, not simply a lack of duplication. The example given is pretty typical actually - where you can frame the problem in a way that your solution ends up without duplication yet the solution requires mental gymnastics to get your head around. We've all been there in…

I disagree strongly. Raw code, that anyone who knows the language can read... is readable!

The OP’s code, which added an invisible abstraction, is “clean” I guess. It’s less repetitive anyway. But it’s not readable. You need to go read the other file to be able to read this one.

It’s like a clean kitchen with everything behind cabinet doors. Yes, there’s less to look at. But you can tell what’s happening without opening all the doors.

Post reply on HN