Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

There’s No Such Thing as Clean Code

steveonstuff.com

Post reply on HN
Print view View original

241–250 of 395 posts

Re: There’s No Such Thing as Clean Code

#241

Post by dtech »

dt3ft wrote: post #151
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.

Sure, in a normal world. But with 2 devs in team, handling a clinical information system in very rapidly changing environment (new features), there is no time to document things in this way.

OK, but that doesn't make it right or good advice. It's just one type of of technical debt due to too much workload.

Re: There’s No Such Thing as Clean Code

#242

Post by sseagull »

skohan wrote: post #153
rawoke083600 wrote: post #135

So True ! After 25+ years of coding, I know one thing. I STILL don't know how to "code correctly". And apart from a few gifted individuals (Rob Pike, Fabrice Bellard Bobby Bingham [ffMpeg team] etc) I'm HIGHLY suspicious of ppl and programmers who claim "they can program correctly" and that "this xyz is the correct way/stack/method/arch". Background:CS grad, start coding at around 13 (thank you dad !) I am well verse…

The more code I've written, the less I care about code quality. I think the things I could point to in my coding practice which would make the code I write now better than the code I wrote 10 years ago would be: - I minimize interdependencies (changing a line of code should not affect something un-related) - I go for abstractions later, only when I need them, rather than trying to think of the perfect abstraction/des…

People who have been coding for a while learn not to repeat their mistakes. Their code contains good-ish abstractions and other “clean code” features because they intuitively know what they are doing. The code they just wrote to get something done & shipped is probably somewhat “clean” by most standards.

But communicating those ideas to less experienced developers is where the problem comes in and all the prescriptive dogma arises.

But this happens in all fields. How many times do experts give some advice they don’t always follow themselves? Experts understand when and how to break the rules, and that comes with experience.

Re: There’s No Such Thing as Clean Code

#244

Post by dtech »

zozbot234 wrote: post #211
serial_dev wrote: post #142

Earlier quoted context omitted.

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…

I thought the best practice for "keeping stuff around just in case" was an attic/ directory in the source repo. That way you're still benefiting from version control, but it's also clear that the code is totally untested and might bitrot at any time.

There's little advantage over that vs looking up the old files in source control.

Re: There’s No Such Thing as Clean Code

#245

Post by sseagull »

gefhfffh wrote: post #205
runald wrote: post #200

Earlier quoted context omitted.

Probably not literally without cost, but if the code was written with disposability in mind combined with just a little bit of pre-planning, then rewriting or refactoring should be indeed trivial.

When start off with "wrong" higher level design concepts, neither of those is trivial. If you're writing a function implementation without thinking about design, well you might be right.

I sometimes wonder if there is a miscommunication. I’m scratching my head sometimes like “how can rewriting/refactoring an entire 10-20k project take negligible time?”

Maybe some people have very small projects compared to what I work on? Or maybe they are talking about the design of a single small component?

I inherited a codebase that needed some refactoring because it was written “to just get it shipped”. If completely fell apart with more users and has taken me a year to get it where it needs to be.

Re: There’s No Such Thing as Clean Code

#246

Post by Rygu »

Hermitian909 wrote: post #107
moonchrome wrote: post #90

Earlier quoted context omitted.

>If you follow them you will end up with code that's really nice to read and easier to maintain, and, most importantly, that you can confidently change. I remember going over unclebob github a while back and this wasn't the impression I got. The parts I read seemed like obtuse code that added pointless abstraction for the sake of following some convention.

This is my experience as well. It takes a long time to grok what the program does and how it does it because of all the layers of indirection, even when the program is fairly simple. While this style might make small changes easy if you understand the code, the inertia to larger changes because of the layers of indirection is immense .

Wow that's on-point, agree that in many past projects "inertia to larger changes" is exactly how I would describe so-called Clean Code.

It's that small changes like adding getters and setters give an easy-to-follow PR, a false sense of accomplishment for both the author and the reviewer, and ton of dopamine with that. While important changes, that actually deliver business value or repay technical debt, become increasingly difficult to do without replacing massive amounts of code and redoing the file structure.

Inertia is the biggest demotivator.

Re: There’s No Such Thing as Clean Code

#247

Post by skohan »

marcos100 wrote: post #222
CipherThrowaway wrote: post #218

Earlier quoted context omitted.

I think this is the kind of thing you learn at uni and then potentially unlearn later on. Over the years I became better at using code to explore problem spaces and as a design tool. Nowadays I feel that incremental design delivers better results in less time than upfront design.

I think your incremental design delivers better results because you already know or at least have a hunch of what wouldn't work and avoid that. You have an abstract architecture when starting and change accordingly on the fly, while programming, using your own best practices. Top down and bottom up architecture have their places. Being extreme in favor of one side is usually bad, as almost anything in life.

I'm just having trouble understanding what you're talking about. Like what would be a concrete example of how a poor up-front design decision would paint you into an unrecoverable corner?

Re: There’s No Such Thing as Clean Code

#248

Post by pards »

I found the light grey font on white background to be almost unreadable.

I persisted in reading it only because the subject matter is compelling but authors should be aware that such typesetting errors can turn people away.

Re: There’s No Such Thing as Clean Code

#249

Post by skohan »

gefhfffh wrote: post #213
skohan wrote: 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…

Well starting from scratch for a rewrite is generally a bad idea. I'm more a fan of incremental re-wrties. But I have code bases I have been working on for years with tens of thousands of lines where basically the entire thing gets rewritten ever 18 months or so, a bit at a time.

Isn't your example proof of the benefit of pragmatic coding? Synapse is actually serving users right now. Dendrite sounds like a "better design" which is stuck in purgatory.

Re: There’s No Such Thing as Clean Code

#250

Post by thfuran »

yakubin wrote: post #231
barrkel wrote: post #212

Earlier quoted context omitted.

Private - or visibility scoping generally - is absolutely essential when you program in an environment with multiple teams. In its absence other people take dependencies on internal details which makes code much harder to refactor later. Lack of scoping on visibility increases the surface area of your APIs and increases the likelihood of bugs. Lack of scoping of visibility on state means losing almost all control ove…

I agree. What I'm saying is that private is a poor default.

Why? I think it's pretty reasonable to only expand APIs deliberately.
Post reply on HN