Given how young the practice of programming is, I doubt anyone alive today knows how to write truly good code. Just look at the kind of code people used to write 30 or so years ago. It's interesting to think about: what will "clean code" look like in 2047?
“Clean code” isn't actually clean
11–20 of 54 posts
Re: “Clean code” isn't actually clean
#12IME the 'best' code solves an existing problem with the least amount of code, is human-readable, and easy to throw away (instead of being 'future proof'). Of course this 'easy to throw away' will also lead to a slow replacement process of 'good code' (that's easy to replace) with new 'bad code' (that's incrementally harder to replace) and eventually each software project will end up in the same broken mess, no matter…
"Easy to throw away" sounds to me like high cohesion, low coupling.
Re: “Clean code” isn't actually clean
#13Essentially you are recommending that people slack off as soon as they face trouble instead of spending time making sure they don't break stuff. Had you mentioned Continuous Integration and many commits per hour I would agree that tests and nurture is less important but you seem to base your thoughts on the laziness of old people.
Re: “Clean code” isn't actually clean
#14Attended a couple of clean code trainings, always wrote the shittiest code for a week or two afterwards. ¯\_(ツ)_/¯
Do you have examples of things you learned on the courses that you thought made your code more difficult to understand and modify?
After that, did you completely switch back to the code style you were using before the courses? Did you cherry pick some things and not others?
Just to make my view plain, for me 'clean code' was the most important book I've read in my career, and what I learned from it has (in my view) massively positively influenced the quality of my code over the years. I'm really interested in getting an opposing viewpoint. At the end of the day I'm aiming for my code to be understandable and maintainable by other people as much as myself.
Re: “Clean code” isn't actually clean
#15This just seems like poor justification for laziness.
You need to keep a project clean. This means profound refactors when concepts for the product change. Some rules are:
- Keep it readable
- Don't over engineering
- Easy to remove
- Good tests (complete, min stubbing, interface oriented. Never refactor and change tests at the same time.
A lot of "veterans" are just resented with new paradigms and too egotistical to stay relevant. It takes effort to maintain a clean project, many will try to say "it's not worth it". That's just out of the question, it's your job, it doesn't have to be always pleasant or easy. If you don't suffer for it a bit now, someone else will in the future (maybe clients or users).
This is what I like about open source projects, it teaches maintaince discipline. In the end, you can sum up all rules into one:
- Make it easy to maintain
Re: “Clean code” isn't actually clean
#16So no data, no examples, no anything. Full of such wisdom as "Testing isn't as important as it might seem but it's still important" The only thing actually articulated was "you don't need 100% test coverage", which is not contrary to existing practice (afaik). I'm not sure the singular point nested in platitudes can be useful to me.
A lot of software engineering practices lean towards tribal wisdom instead of being evidence-based. The only resource I know of that provides citations to studies is Code Complete by McConnell. But having data is no guarantee of correctness. Bossavit debunks some SWE common sense in "The leprechauns of software engineering", including the cone of uncertainty which is referenced by McConnell. I'm also planning on read…
Shouldn't everyone demand more before promoting ideas without any basis? (https://vimeo.com/9270320)
Even if it is just "tribal wisdom", is HN where you recruit a tribe from a vapor posting? I would hope you at least have a tribe before upvoting it up the pile. It feels like it's being promoted for no reason or through a backchannel.
It didn't even give a wiki link to the Chesterton's fence analogy. Sigh.
Re: “Clean code” isn't actually clean
#17IME the 'best' code solves an existing problem with the least amount of code, is human-readable, and easy to throw away (instead of being 'future proof'). Of course this 'easy to throw away' will also lead to a slow replacement process of 'good code' (that's easy to replace) with new 'bad code' (that's incrementally harder to replace) and eventually each software project will end up in the same broken mess, no matter…
Replace `least amount of code` with `least amount of complexity` and I completely agree!
Yes, else it ends up as some form of Perl Golf
Re: “Clean code” isn't actually clean
#18On my side projects at home, I can't even remember the last time I had to slow down or got stuck on maintenance/integration type stuff (as opposed to new functionality or algorithms, which don't rely on existing code). And I have a couple of fairly big ones, it's not all "Todo list" stuff. It's happened constantly at work though, throughout multiple jobs. Sometimes I've been so stuck I've got basically nothing done f…
I'm going to start using NPM Lego, thank you.
Re: “Clean code” isn't actually clean
#19This guy mix and match totally unrelated things.
- clean != finished
- clean != perfect
- ugly is not clean
- you can understand a code and find it still ugly
What is he actually talking about?
> Automated tests are not that important
I agree with the content of this section, but the title is bad.
Re: “Clean code” isn't actually clean
#20So no data, no examples, no anything. Full of such wisdom as "Testing isn't as important as it might seem but it's still important" The only thing actually articulated was "you don't need 100% test coverage", which is not contrary to existing practice (afaik). I'm not sure the singular point nested in platitudes can be useful to me.
A lot of software engineering practices lean towards tribal wisdom instead of being evidence-based. The only resource I know of that provides citations to studies is Code Complete by McConnell. But having data is no guarantee of correctness. Bossavit debunks some SWE common sense in "The leprechauns of software engineering", including the cone of uncertainty which is referenced by McConnell. I'm also planning on read…
If we went for the evidence we’d all be pair programmingband doing some form of agile development.
It would be nice, and it’s backed by various studies, but we’re not.