Live data from Hacker News

There’s No Such Thing as Clean Code

steveonstuff.com

311–320 of 395 posts

Re: There’s No Such Thing as Clean Code

#311
post #288
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.

Not having to pay for physical materials doesn’t mean there are no costs. Throwing hours, days, or weeks of focused work time out the window does not sound cost free to me or Whoever signs paychecks.

It's not throwing it out the window if it's an iteration toward a better solution. There's a reason nobody does waterfall anymore in software - up-front planning is less productive than rapid prototyping in most cases.

Re: There’s No Such Thing as Clean Code

#312
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…

This is a very self-centered way to think about things. I don’t mean selfish, I mean thinking as a “me” problem instead of an “us” problem. If I have to rewrite a bit of my code then them’s the breaks. But I work on a team, sometimes a big team. I don’t have “a house” I have a construction crew that is building many houses and will go on building them. If they’re doing it wrong then I have not only the problem in fro…

I want to work with people who I trust to rewrite my code.

And of course I don't mean that you should check in code which is a mess. But from the time you start a feature to the time you open a PR, you can go through several iterations of messy code before arriving at a solution which is fit to share with your colleagues.

Re: There’s No Such Thing as Clean Code

#313

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…

Weeks of programming can save you hours of planning!

You can also spend weeks trying to solve a problem on paper which can be solved with hours of experimentation

Re: There’s No Such Thing as Clean Code

#314
post #92
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…

I have started to prefix my actual comments with another character after the comment character, e.g., #: in Python. Then I know which comments are “real,” and which are just garbage code that can safely be ignored/deleted.

Re: There’s No Such Thing as Clean Code

#315
post #292
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.

Are you the only working on the codebase? It may be easy to rewrite your own codebase, but it's certainly not easy to rewrite someone else's. Especially if they haven't been caring about code quality and/or test coverage. My definition of "good-quality" code is pretty much exactly "how difficult would this codebase be for a new engineer to understand and modify safely."

Idk maybe it's because I did freelancing for quite some time and was often hired to clean up somebody's mess, but I think it's not so bad to rewrite someone else's code. What I normally do is quarantine the old code behind a clean interface, or else start fresh with a better code structure, and then copy and paste the good bits of business logic from the old project into the new one.

Code has a lot of really great properties which make it easy to modify in provably safe ways if you know what you're doing.

Re: There’s No Such Thing as Clean Code

#316
There is clean code, but I wouldn't say so generally. Each team should decide form themselves what constitutes clean code as a set of guidelines with documented motivations. Every now and then or as deemed necessary update and evolve the guide. As the codebase matures (in good and bad ways) so should the guiding principles change in weights.

Re: There’s No Such Thing as Clean Code

#317
post #210

Earlier quoted context omitted.

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.

Some examples of high-level decisions: - which web framework? - which database? which ORM? which transaction isolation level by default? - will this game/UI be multiplayer? - what's our testing discipline? You can't loosely couple around questions like these most of the time, at last not without excessive abstraction. For "how do I structure this reasonably isolated 0-1kLOC component", I agree, easy to fix later if n…

I think there are always ways to minimize coupling. For example if most of the code you write is pure functions operating on values, then swapping out your ORM might be a bit laborious, but it's going to be largely just a matter of typing, not tricky problem solving.

And like for example if you want to change web frameworks, that's something you can do incrementally. If you're talking about front-end, just find a way to encapsulate your old code behind a clean interface and start implementing new components in the new framework. If you're talking about back-end, then you can just implement new endpoints in a new language if you want even, and gradually migrate things over when you have to modify them.

Re: There’s No Such Thing as Clean Code

#318
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…

very important lesson, more than that actually there's a lot of artistry, poetry, idealism in programming, but as a daily money making activity it just doesn't cut it. You have to reach goals as easily as possible (dry,yagni) fast without painting yourself in corners as much as you can (low coupling, min interdependencies). Finding the right variability points. it's something school don't do well (saying this humbly)…

Yeah I think that there's a bias for programmers to think about artistry, poetry, and idealism in the form of code since that's what we're dealing with all day. But in reality it matters a lot less than we would like to think.

Re: There’s No Such Thing as Clean Code

#319
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…

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 prescriptiv…

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

I think a lot of it is just lack of context. A lot of "best practice" advice is valuable in certain cases but it gets over-applied, and people end up wasting a lot of time on things which don't matter.

Post reply on HN