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

201–210 of 395 posts

Re: There’s No Such Thing as Clean Code

#201

Post by dt3ft »

qayxc wrote: post #193
dt3ft wrote: post #151

Earlier quoted context omitted.

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.

Jump ship then. This sounds like you're travelling towards burnout at supersonic speed. Rapidly changing environment/features is just newspeak for customer has no idea what they even want in the first place and project management is non-existent.

I agree and did jump ship. This was in Switzerland, by the way.

Re: There’s No Such Thing as Clean Code

#202

Post by azangru »

> Clean’ isn’t a measure of anything useful. Code can’t be clean simply because ‘clean’ doesn’t describe anything about code.

"Clean", famously, is measured in WTFs/minute. The fewer WTFs, the cleaner the code; and having a low-WTF code is useful for a programmer to read and modify and be happy.

Re: There’s No Such Thing as Clean Code

#203

Post by skohan »

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

When can you rebuild at zero cost? I have made similar avoidable mistakes of not thinking it through enough, could have saved me a lot of rewriting, which was pretty expensive

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.

Re: There’s No Such Thing as Clean Code

#204

Post by [deleted] »

lifeisstillgood wrote: post #167
karatinversion wrote: post #116

Earlier quoted context omitted.

> Hide internal structure (that "private" is the default in C++, Java and Rust just adds to boilerplate; the default case is that you want everything public (unless you like writing trivial getters and setters just for the fun of it); legitimate uses of "private" exist, but are rare) This is such a strange POV to me. There are cases where your classes are just data records, but any object with logic surely wants to r…

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…

[deleted]

Re: There’s No Such Thing as Clean Code

#205

Post by gefhfffh »

runald wrote: post #200
gefhfffh wrote: post #188

Earlier quoted context omitted.

When can you rebuild at zero cost? I have made similar avoidable mistakes of not thinking it through enough, could have saved me a lot of rewriting, which was pretty expensive

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.

Re: There’s No Such Thing as Clean Code

#206

Post by cerved »

yakubin wrote: post #96
onion2k wrote: post #59

The Uncle Bob Martin definition of "clean code" from his book "Clean Code: A Handbook of Agile Software Craftsmanship" is a set of rules that absolutely are not at odds with one another. 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. There's a decent summary here - https://gist.github.com/wojteklu/73c6914cc446146b…

> 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 found that a lot of those guidelines lead to the exact opposite. Examples: - Prefer polymorphism to if/else or switch/case (oh, the joy of tracing a simple task through 50 files) - Use dependency injection (same as above) - Hide internal structure (that "private"…

> Prefer polymorphism to if/else or switch/case (oh, the joy of tracing a simple task through 50 files)

If this is arduous it may be worthwhile to change your dev environment

Re: There’s No Such Thing as Clean Code

#207

Post by mpartel »

jcbrand wrote: post #168
skohan wrote: post #153

Earlier quoted context omitted.

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…

Back in university I had an experience that was really instructive. For a project we had to write a program that differentiates mathematical equations. I dove in and just started writing code. Eventually, I realized that I had made a design error and that my code was much more complicated and cumbersome than it needed to be and I was getting stuck due to the complexity of the monstrosity I created. Unfortunately I fi…

This is true for early high-level decisions. For every-day coding of smallish components in a large project, it matters much less.

The more code your design decision will affect, the more up-front planning it deserves.

Re: There’s No Such Thing as Clean Code

#208

Post by cerved »

dt3ft wrote: post #92
onion2k wrote: post #59

The Uncle Bob Martin definition of "clean code" from his book "Clean Code: A Handbook of Agile Software Craftsmanship" is a set of rules that absolutely are not at odds with one another. 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. There's a decent summary here - https://gist.github.com/wojteklu/73c6914cc446146b…

> Don't comment out code, just remove I hate commented out code, but this doesn't work in every situation. While working on a clinical information system, we had frequent "please bring it back" requests that came a few months after things were removed (also by request). Relying on source control is nice, but unless you document every feature/removal or use very extensive commit messages, finding the code that was rem…

  git log -p -- file

Re: There’s No Such Thing as Clean Code

#210

Post by skohan »

mpartel wrote: post #207
jcbrand wrote: post #168

Earlier quoted context omitted.

Back in university I had an experience that was really instructive. For a project we had to write a program that differentiates mathematical equations. I dove in and just started writing code. Eventually, I realized that I had made a design error and that my code was much more complicated and cumbersome than it needed to be and I was getting stuck due to the complexity of the monstrosity I created. Unfortunately I fi…

This is true for early high-level decisions. For every-day coding of smallish components in a large project, it matters much less. The more code your design decision will affect, the more up-front planning it deserves.

I would argue if “high level design decisions” are getting in the way of coding, this is a sign of over-design or premature abstraction. If you write sufficiently loosely-coupled code, it’s not hard to re-organize later.
Post reply on HN