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

341–350 of 599 posts

Re: Goodbye, Clean Code

#341

Post by einpoklum »

A lot of duplication is:

* A recipe for typo-based-bugs.

* Makes the code difficult to read if there are subtle differences, since they get lost among the identical repeated parts.

* Indicates that there is (probably, not necessarily) a meaningful abstraction you could have used.

I would say it's technical debt, that needs to be paid. Perhaps not immediately, but don't let it pile up.

So: Don't "let it go"; rather, pursue it somewhat more flexibly.

PS - There is more to clean code than less duplication...

Re: Goodbye, Clean Code

#342

Post by einpoklum »

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…

> There isn't much code I wrote in my previous professional career that is still live

That means your impact on the world has been very limited. You haven't contributed to the basis of what other coders used. Not that this is illegitimate - but I believe we should strive further.

> the reason is vendors only make a profit because they need to generate cashflow constantly, and they do it by breaking the above rules unnecessarily.

1. "vendors" don't control all code. In fact, the most important bodies of code we all use were released for general use rather than sold commercially: Free Software libraries, drivers, kernels and applications.

2. Not all commercial companies want you to write this kind of throw-away code.

Re: Goodbye, Clean Code

#343

Post by Joeri »

scarface74 wrote: post #292
Impossible wrote: post #217

Earlier quoted context omitted.

Future coding has lead to some of the most overcomplicated systems I've worked with. It's one of the reasons (among many) I quit my last job. I was constantly told code that had no use cases was "important to have" because "we needed it".

So does that same idea apply to all of the many abstractions thst geeks do just to stay vendor or cloud agnostic just in case one day AWS/Azure go out of business?

On the other hand, I worked on a multi-million line codebase that was deeply joined to oracle’s db, with a team who all really wanted to move away from it but couldn’t because in the beginning (a decade earlier) the choice had been made to not put in “unnecessary” abstractions.

Re: Goodbye, Clean Code

#344

Post by WoodenKatana »

>Obsessing over clean code is like reorganizing your clothes closet on a daily basis. If it makes you more productive to do so, do it. Too often, however, it's done compulsively and is counter-productive.

Re: Goodbye, Clean Code

#345

Post by kortilla »

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…

That’s the behavior of a junior engineer though. It’s a sign of an inferiority complex where any change feels like some kind of judgement on your ability to write it “correctly” the first time.

You are not your code, the code you wrote is not representative of you. Nobody who rewrites your code thinks that either.

You’re on a team working to build something larger than yourself. You’re not a bunch of painters sitting with your own easels in a room hoping to tape all of your paintings together in the end.

The best engineering teams I’ve ever worked on were groups of people that had no issues at all modifying each other’s code because we all trusted each other to do the right thing. The worst were the ones where each module had one “owner” who handled all of the changes to their module and “nobody else’s”.

Re: Goodbye, Clean Code

#346

Post by pvorb »

valand wrote: post #311
bcrosby95 wrote: post #276

Earlier quoted context omitted.

The rule of 3 usually is in reference to small scoped abstractions, not whole modules or subsystems. We're talking about extracting a short function, not significant and potentially thorny chunks of code. But I guess no one explicitly spells this out, so I could see where someone could become confused.

Premature abstraction. Rule of 3 helps. But I found better principle for it: Any abstraction MUST be designed to be as close as possible to be language-primitive-like. Language primitives are reliable, predictable, and non-breaking. If they do, they don't affect business logic written on top of it. If parameters are added, defaults are provided. They don't just abstract, they enable developers to express business log…

I find abstractable parts in code by thinking about potential names for it. If there is no good name for a potential common function, it's probably not a good idea to extract the section into a function. Maybe it can be extracted into two separate functions with good names?

Re: Goodbye, Clean Code

#349

Post by pvorb »

hyperpallium wrote: post #283
Stratoscope wrote: post #281

Earlier quoted context omitted.

Yes, exactly, and it is such a good rule to go by so much of the time. But like many rules, you need judgment to know when to apply it.

Rules are a poor substitute for actual thought.

You nailed it. I will print this and hang it on the wall in our office.

Re: Goodbye, Clean Code

#350

Post by cellularmitosis »

kortilla wrote: post #335
cellularmitosis wrote: post #221

Earlier quoted context omitted.

This actually happened to me, (and his rewrite didn’t even work!). Having witnessed this first-hand, I can say that the impact of the code change was absolutely dwarfed by the lost trust. Unsurprisingly, I would come to find out that this engineer had what I would call the opposite of soft skills, and the notion of a “this irks me so I rewrote your code” has become a giant red flag for me.

Did you lose trust because the code broke (a legit reason to lose trust) or because your code was changed without kissing your ring (a problem with you being too attached to your code emotionally).

Having a conversation and “kissing my ring” are not the same thing by a long shot, but that sure is a pretty strawman!
Post reply on HN