Live data from Hacker News

There’s No Such Thing as Clean Code

steveonstuff.com

381–390 of 395 posts

Re: There’s No Such Thing as Clean Code

#381
post #337
post #173

Earlier quoted context omitted.

Yeah this just hasn't been my experience. If you're working on a house you measure twice and cut once because the cost of reworking physical materials is a lot more expensive than the cost of doing a second measurement. If you could delete half your house and re-build it at zero cost, it might be more valuable to just go for the first attempt and learn from it rather than trying to do everything in theory up front. I…

I don't know about your experience but refactoring is just not on the menu in most commercial environments I'm familiar with, therefore if you always pick the first solution that cones to find, it is likely you have to leave with the consequences of the hack for a long time (until the system crumbles under its own complexity).

I refactor all the time and have done it for 25+ years. The result is solid code that is easy to maintain and close to bug free (no bugs in production the last 5+ years).

Re: There’s No Such Thing as Clean Code

#382
post #337

Earlier quoted context omitted.

I don't know about your experience but refactoring is just not on the menu in most commercial environments I'm familiar with, therefore if you always pick the first solution that cones to find, it is likely you have to leave with the consequences of the hack for a long time (until the system crumbles under its own complexity).

I refactor all the time and have done it for 25+ years. The result is solid code that is easy to maintain and close to bug free (no bugs in production the last 5+ years).

Could you describe the process: did you need to justify the time spent on refactoring in any way? ("why known bugs, requested new features should wait until the refactoring is done"--I'm playing devils advocate here. I'm interested, how you justified it before the management if you had one)

Re: There’s No Such Thing as Clean Code

#383

Earlier quoted context omitted.

This is where Python's "consenting adults" idea comes in. Why the hell should someone change a vector "mid-flight" - that is a huge code smell and should be dealt with in the review / design / discussion / pub. But there are reasons and rationales to "lockdown" the code (beyond not trusting fellow devs!) and at that point I suggest that any mutable state language cannot be properly locked down - so use a functional l…

In most situations, no you can not trust fellow devs to do the right thing and if you push for those reviews then you're the asshole and lose the office politics game. So yeah, I'd rather guardrail people into good behavior.

Can I clarify? You get a review that just looks wrong and you become the asshole? What kind of reviews are these ?

Re: There’s No Such Thing as Clean Code

#384
post #203

Earlier quoted context omitted.

Rewriting is incredibly cheap! And you learn a lot from the failed attempts. Again to the house analogy, if you could just build 3 vestibules to see how they fit with just a little typing, that would be far and away preferable to committing to everything on paper before hand.

No, it is not cheap, generally. Example: Dendrite[0] was going to be a Rewrite of Synapse (which was a prototype which ended up going into production). The rewrite started more than 5 years ago, had lots of development breaks and it still is nowhere complete or close to replace a existing Synapse instance (which even today is ... Well ... suboptimal software). The current plans are to support and use both servers lon…

Survivor bias.

You don't see all the perfectly designed codebases that never went anywhere.

We only talk about legacy code because it's the one that pays the bills.

Re: There’s No Such Thing as Clean Code

#385

Earlier quoted context omitted.

In most situations, no you can not trust fellow devs to do the right thing and if you push for those reviews then you're the asshole and lose the office politics game. So yeah, I'd rather guardrail people into good behavior.

Can I clarify? You get a review that just looks wrong and you become the asshole? What kind of reviews are these ?

please ignore the above. I am sure reviews can become political arenas

Re: There’s No Such Thing as Clean Code

#386

In my 5th role where I write code, and I have dealt with so many different approaches and definitions of "best practice" that at this point I just roll over to whatever the generally agreed approach is at my current org and mimic it as best as possible. In one organization, I have even had two seniors go back and forth telling me to remove what the other senior told me to put in. The entire process of defining "clean…

> In one organization, I have even had two seniors go back and forth telling me to remove what the other senior told me to put in.

From: You

To: Senior1, Senior2, Senior1s_Manager, Senior2s_Manager, Your_Manager

Subject: Duke it out between yourselves

Senior1, you told me to put in Feature1, Feature2, and Feature3. A while later, Senior2 told me to take them out.

Senior2, you told me to put in Feature4, Feature5, and Feature6. A while later, Senior1 told me to take them out.

My job is to implement worthwhile features, not to be an implement in your quarrel over which features are worthwhile to implement. Duke that out between yourselves, and only then give me the ones you can agree on to implement. Thank you.

Your_Manager, I've looked over my job description. It says my job is to implement worthwhile features, not to be an implement in other people's quarrels. Yours says your job is to back me up in situations like this.

Senior1s_Manager and Senior2s_Manager, maybe Senior1's and Senior2's job descriptions need to be clarified with regards to which features each of them is empowered to request or veto.

Re: There’s No Such Thing as Clean Code

#387

Theres definitely clean code, theres just no rule book for how to define it or course you can teach for how to write it. Some people are just better at the art of writing simple software. You definitely know it when you see it.

I agree. The article (well the little I read of its unreadably thin font) doesn't even really argue that there's no such thing as clean code, just that it's not very well defined. Well sure, but that's like saying "there's no such thing as beauty" or "there's no such thing as a well-written book". Clearly bullshit. They might be somewhat subjective and have no mathematical definition but they clearly exist.

> well the little I read of its unreadably thin font

Try pressing F9.

Re: There’s No Such Thing as Clean Code

#389
post #382

Earlier quoted context omitted.

I refactor all the time and have done it for 25+ years. The result is solid code that is easy to maintain and close to bug free (no bugs in production the last 5+ years).

Could you describe the process: did you need to justify the time spent on refactoring in any way? ("why known bugs, requested new features should wait until the refactoring is done"--I'm playing devils advocate here. I'm interested, how you justified it before the management if you had one)

I never asked permission to do it. I consider refactoring to be part of my job. Small refactorings I do right away when implementing a new feature. Large ones I split into many small steps and work on for months in-between working on new features. Never underestimate the power of making a small improvement every day. I make sure that the long term refactorings never breaks the system or introduce new bugs. I have solid tests in place making sure changes doesn’t change behaviour.

Re: There’s No Such Thing as Clean Code

#390

Earlier quoted context omitted.

I agree, except I think that a lamdba is an arbitrary line to draw for that as well. Why not stop at the main function and give it a load of inputs? A five line lamdba looks a lot like a named function, just harder to test, reuse, and debug in a stack trace.

I was basing my comment on this: > 20 short functions definitely sound as though they should be explicit. And you are right that it's pretty arbitrary when/if a lambda should specifically be tested or not. But the number of lambdas in a project isn't really a good factor to make that decision - it's individual for each function that contains a lambda.

Well, I more meant that if they're "short" as opposed to "20 character one-liners" then it sounds as though they should be tested, whether or not they're defined using lambda syntax.
Post reply on HN