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

301–310 of 599 posts

Re: Goodbye, Clean Code

#301

Post by yawaramin »

Stratoscope wrote: post #262
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…

The Rule of 3 is a great rule, except when it isn't. I had a colleague some time ago who wrote a couple of data importers for FAA airspace boundaries. There were two data feeds we cared about, "class airspace" and "special use airspace". These airspace feeds have nearly identical formats, with altitudes, detailed boundary definitions, and such. There are a few minor differences between the two, for example different…

> But because of blind obedience to the Rule of 3, there were many thousands of lines of code duplicated, both in the importer and in its downstream clients.

Well sure, blind obedience to anything at all can cause problems.

Re: Goodbye, Clean Code

#302

Post by sev »

As @hyperpallium said,

> Rules are a poor substitute for actual thought

There are many times "clean code" is a good goal to have. It depends on what you mean by "clean code" and what you mean by "deduplication". As with many things in software engineering, the best answer to whether you should strive for "clean code" is "it depends."

If you have a utility function that you are redefining in every file, literally copy/pasting it everywhere, then you might as well create a shared function and import it and use it everywhere instead. This is an example of a good goal.

Re: Goodbye, Clean Code

#303

Post by vbezhenar »

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…

Another approach with statically compiled language and good IDE might be to reduce duplication whenever you see it and inline back when you feel that this abstraction is no longer useful.

Re: Goodbye, Clean Code

#304

Post by pizzazzaro »

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…

Always fun to find an escapee of the "Russian nail factory" of modern business management. Thank you for this simple, clear explanation.

Re: Goodbye, Clean Code

#306

Post by valand »

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 totally disagree one million percent! If you are on my team and you want to rewrite code I wrote (cause it sux) then do it! Don't ask, just DO IT! DO IT NOW! Have a blast, tear it apart, rewrite all my shitty abstractions and see if you can do it better. If the result is better code, then awesome! I learn something and the software gets better. If the result is worse code, then awesome! I'll tell you why, you'll learn something and your improved understanding will allow you to write better code.

I see your point of view.

There is a need to detach from your code while still being passionate in programming.

The key is the mindset: programming so that people enjoy what you're programming and not just for the sake of programming.

Also, to note, the refactor presented should objectively serve the same cause/requirement better than current code.

I've been a lead myself here and what danabramov nailed is that he realized this:

> My code traded the ability to change requirements for reduced duplication, and it was not a good trade.

His refactor is a form of premature abstraction

Re: Goodbye, Clean Code

#307

Post by pizzazzaro »

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…

That sense of "ownership" in some small piece of the product? Helps build loyalty to the project, and the company. Seeing my baby with that brand name on it helps me feel a part of the team. I've left many a project that didnt offer me the loyalty of letting me fix my own mistakes (after some guidance).

Toe-stepping aside... How else are you going to develop this apparently inefficient coder without including them into the process of reforming this code? This isnt just about ego, this is about skill. This is about the code Im gonna write in the future. And here's your opportunity, written in our codebase.

Unless, of course... Im disposable as your coder.

Re: Goodbye, Clean Code

#308

Post by nojvek »

1) Always do pull requests. No change should make it into a master without someone else’s eyes. Unless it’s a “get out of trouble” surgical revert that really needs to go out in an emergency.

This would have given the author to raise concerns about very duplicated code. We do that all the time with comments like “this could be a bit DRY-er, how about moving this bit to a common place with this other bit in the codebase that also does that”

2) when the author refactored code, he should have deffo asked for OG to review his code. May be his duplication didn’t account for edge cases.

Reviews are great. Make reviews a part of the system. Small, incremental reviewed code, with decent coverage, being shipped multiple times a day by CI, reacting to customer needs is how the best engineering orgs are operating.

He is right about some parts of over accounting for the future. I’ve had that happen to me multiple times.

Same with doing large refactor s of other people’s code. It’s not about code anymore, you gotta ensure they feel good about it too. Esp junior engineers, it has to feel that it’s still their work.

Re: Goodbye, Clean Code

#309

Post by jdnenej »

BinaryIdiot wrote: post #295
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 also think that a salaried engineer who thinks that a piece of code he or she (but almost always he) wrote is "his" or "hers" is totally wrong. It's the company's code. While this is _technically correct_, this isn't how humans work. Humans attach their worth to things they do, even when they shouldn't. It's a difficult thing to avoid to most people so if you write some code, commit it and then later see a teamma…

This is how some humans work. No one on my current team has ever expressed disatisfaction when their code gets changed.

Re: Goodbye, Clean Code

#310

Post by grogenaut »

scarface74 wrote: post #25
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…

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…

Old boss of mine had a great line: "two points always make a line, but three usually makes a triangle"
Post reply on HN