There’s No Such Thing as Clean Code • Hacker News Board

Re: There’s No Such Thing as Clean Code

#391

Post by smaudet » Tue, Feb 01, 2022, 3:09 PM UTC

There is no such thing as "clean code", I think its a verb, not a noun. Same problem as being virtuous, there is no such state. But you can attempt to do things well, make moral choices, etc.

Specifically, when we first bang out that initial solution, the code is "dirty". As we refine that approach (better algorithms, adjusting terminology to better accommodate underpaid colleagues), we "clean" it, but the truth is the new code isn't in a "cleaner" state. The little bubble of local opinion might reflect better against said code, but that's hardly an objective measure.

Re: There’s No Such Thing as Clean Code

#392

Post by smaudet » Tue, Feb 01, 2022, 3:11 PM UTC

brianmcc wrote: post #36

ahmaman wrote: post #29

Clean code is code that does what you expect it to do without many surprises. It is simple, not clever. Effortless to follow. Each part handles one idea at a time, at the same abstraction level. Doesn't force you to mentally juggle many balls at the same time. The code often tells you a story, it communicates how the programmer (author) described the problem, the solutions and the trade-offs. Very similar to writing.…

>> It is simple, not clever. Effortless to follow. This is the crux of it for me. I want to read code not solve code. If I have to "figure out what's going on" then it's not great code.

An entirely subjective measure. I want to solve problems, not read code. I can read your code and understand it, but then still have to solve it to understand what problem you are solving.

Re: There’s No Such Thing as Clean Code

#393

Post by RMPR » Thu, Feb 03, 2022, 4:14 PM UTC

serial_dev wrote: post #142

dtech wrote: post #110

Earlier quoted context omitted.

Seems garbage advice to me. Now you've polluted your production code, likely forever. I don't see a situation where using an issue tracker + good commits - e.g. 1 commit for the 1 PR linked to the ticket that removes the feature - won't result in a superior situation from a maintenance and traceability perspective.

Yes, I agree with you. Another thing is how do you know which of the removed features will be asked to be put back? You can't really know. You can guess, but that will leave you with many classes/functions commented out only in the hope that one day one of them will be requested to be put back. This leads to nobody daring to remove old code for months/years. Then, one day, a new coder on the team just ask WTF is this…

One solution might be to create a separate branch with the feature still available. With time, you kind of get the gut feeling of what could be useful later and what could not.

Re: There’s No Such Thing as Clean Code

#394

Post by [deleted] » Thu, Feb 03, 2022, 7:04 PM UTC

skohan wrote: post #267

Aqueous wrote: post #233

Earlier quoted context omitted.

As someone who is currently over a year into rewriting a massive system with a fundamental design error by the original designer I can assure you that failing to plan your data model up front can have huge costs not just for you but for anyone who picks up your code in the future, and can hamstring a system so that it is impossible to extend or evolve.

What was the design error?

[deleted]

Re: There’s No Such Thing as Clean Code

#395

Post by Aqueous » Thu, Feb 03, 2022, 7:06 PM UTC

skohan wrote: post #267

Aqueous wrote: post #233

Earlier quoted context omitted.

As someone who is currently over a year into rewriting a massive system with a fundamental design error by the original designer I can assure you that failing to plan your data model up front can have huge costs not just for you but for anyone who picks up your code in the future, and can hamstring a system so that it is impossible to extend or evolve.

What was the design error?

It's a platform for managing a kind of appointment, but it doesn't have an appointments table. The appointments data is combined with a different table, and there was no way to disentangle them easily because the entire system was built around that object model. Case study in failure to normalize.

The hard part is done, but basically we had to switch the engine while the car was running so to speak. In order to switch this out you need to start writing the correct data shape, then switch everything over to reading that shape. When people work strict 9 to 5s this will take you forever especially when managing a large amount of volume, which requires you to be extremely risk-averse and slow.