YAGNI?
“Clean code” isn't actually clean
21–30 of 54 posts
Re: “Clean code” isn't actually clean
#22Given 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?
This seems to couch the idea that older professions finally "understand it." Look at the houses people made 40 or so years ago. We now have to have disclaimers indicating that the materials they used were... not so wise to be used.
Go back further, suddenly you will be left with basically nothing but survivor bias. It will seem like they had it together, but it is just as likely they did not. Pull it in some and you get the hastily built houses that seemed to fall apart way too easily.
I feel like this can go with software. It is actually trivial to find software that is still is use from the 80s. Older fortran code still exists. It is far harder to find any lessons in those software packages. Even when I desperately want to.
Re: “Clean code” isn't actually clean
#23This 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…
I experienced while writing a lot of tests, the code suddenly became
- more readable
- less over-engineered
- replaceable
- easier to maintain
since it's easier to write tests for "clean code".
Re: “Clean code” isn't actually clean
#24YAGNI?
You Ain't Gonna Need It. (I think)
Re: “Clean code” isn't actually clean
#25Attended 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) m…
The single most dangerous thing I learned was that "cleaning" as you go and the "intrinsic quality of the code" were somehow paramount.
I'm not against the ideas, per se. But they have a cost. And at the end of the day the quality of the product you are building is far more important than any intrinsic quality of the product. Worse, it would be nice if they correlated, at the least. They don't seem to, IME. I'd be welcome to data showing otherwise. Make sure you understand your budget. And for the love of god, realize that idioms in the codebase and in the general programmer pool are more important than purity of some style.
Re: “Clean code” isn't actually clean
#26Given 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?
This seems to couch the idea that older professions finally "understand it." Look at the houses people made 40 or so years ago. We now have to have disclaimers indicating that the materials they used were... not so wise to be used. Go back further, suddenly you will be left with basically nothing but survivor bias. It will seem like they had it together, but it is just as likely they did not. Pull it in some and you…
Sure, but we've been building houses for a long time. We know a lot more about building houses today (or even 40 years ago) than they did when the practice of house-building was still relatively new. And most of this knowledge didn't come from building houses over and over, but from developing better theories of how buildings stay up, using better materials, etc....
Re: “Clean code” isn't actually clean
#27Most guru's take an 'all or nothing' approach, this goes beyond programming, look at food-guru's "eat only carbs, never eat refined sugar" etc. This is for me the same as "always do TDD, never use static methods".
People without experience often look at guru's because they can not yet think for themselves.
I'm a developer in my 40s, have done a lot of projects in a lot of different companies. Having this experience gives me intuition about what to do in what situation. I just (think I) know when I should write a unit test and when not.
The 'all or nothing' attitude is created by people who want to be guru's and is followed by people who want to have some guidance.
This is not a bad thing, it takes time to shape yourself as a programmer. This takes years: http://www.norvig.com/21-days.html
Learn from the guru's, and be consious, people preaching an 'all or nothing' view of the world are NEVER right :)
Re: “Clean code” isn't actually clean
#28Criticizing code for not being "clean code" is 70% of the time "I don't like this code for various reasons"
Not to mention of the pedantism of one of the biggest proponents of clean code.
So, in essence, worry that your code has a certain quality but in the end all projects will end up in the trash can. It's software, not the Mona Lisa.
Re: “Clean code” isn't actually clean
#29Attended 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) m…
I agree, Clean Code was the most important book for me too. But I wouldn't follow it blindly. Also, it's less useful for non-Java and much less useful for non-OOP languages (it's ok to have a focus, but one has to keep in mind that sometimes, certain idioms, best practices or design patterns are actually workarounds around the limitations of Java).
My favorite example: Overdoing the short functions thing. I've seen this a lot. Unsurprisingly, considering that for most devs, when you ask them what makes good code, "short functions" seems to be the first thing that comes to mind.
Splitting code into extremely short functions has a few disadvantages too: a) in what order they're called is not immediately clear, b) where they can be called from is not immediately clear, c) going up/down the stack can make it harder to follow when debugging interactively. d) It increases the LOC and noise. And e) especially in OOP languages, short methods make it more tempting to turn variables into attributes to avoid passing them around explicitly (bad due to longer lifetime).
Splitting functions should only be done if it makes sense semantically. Each function should make sense on its own. If some logic is highly cohesive (e.g. because it implements a specific algorithm), not independently reusable, and it's subblocks only make sense in one order, and it all fits on a few screenfuls, it might make sense to keep it in one longer function instead of dividing it into fairly arbitrary chunks.
Re: “Clean code” isn't actually clean
#30I think the problem here is that 'clean' is an umbrella term for a bunch of different things. To sum them it is: 'how does this code make me feel inside'. But what goes into that are: readability, extensibility, maintainability, testability, clarity, correctness, simplicity, and yes, aesthetics. Some of these are objectively always good, and some of them are contingently good.
For instance, a simple algorithm for distributed consensus is probably not correct, and you should rightly not view it as 'clean'. Some things simply aren't simple. The goodness of simplicity is contingent on the complexity of the problem.
But aesthetics is at the final end of the spectrum: it's purely subjective. And yet we wrap all these things up under the term 'clean', and so it is confusing. People will defend their notion of cleanliness using the objective standards, and then apply it to the subjective cases.