So I recently started reading CleanCode by Robert C Martin .
He raises some exceptionally strange points about writing professional clean code which I didn't knew at all.
Like minimising comments in our code, keeping function arguments to less than 3 and many more.
On the other hand I found this article somewhere in my social media.
Casey Muratori on 'clean' code
I know there are tone of professionals on DEV, would like to read their insights about this 👀
What do you think how much should one focus on writing Clean Code?
Does it matter?
Top comments (17)
I haven't actually read Clean Code, but according to what I've read on the internet about it, it seems to make some reasonable points.
About Muratori's rant, I have a few objections.
Those two points only hold true as long as you write code once and never again need to modify it. If you have code that is messy and ugly, and you haven't touched it in a few months, and now have to implement a new feature there, even if it runs perfectly for its originally intended purpose, then you're in a worse position than if you would have spent some time making the code easy to read, modify and reason about.
My experience is that code quality tends to degrade over time and it requires great commitment, discipline, and agreed-upon rules to keep it in good shape. Maybe Muratori has only worked with better developers than myself and thus our experiences differ.
I do agree with the 3rd and 5th points, although I think that the phrasing of the 3rd point is a bit unfortunate.
You make excellent points - seems to me it's a case of not mentioning what your world looks like. It seems to me a lot of our development arguments online boil down to different experiences.
If all your colleagues write good, buff y free code, tests aren't that important, neither is clean code.
If your colleagues don't know what a function is, and development is buggy and takes ages, then it's super useful.
That's why I love the talk "The hidden assumption of agile" by Fred George.
Agile is built on clean code, but nobody bothered to say it at the time because they all wrote clean code by default.
I guess the entire point of the book is to just try to make your code readable for others, not just to yourself.
About Casey's writing I'd say that he is probably one of the best developers alive, I've never came across a code that would clean up over time.
I like to practice a few of its principles because I know how hard is to read someone else's code and be completely lost for hours on simple things.
I believe that single purpose functions, few parameters, size and scope of classes and functions matter and most importantly: comments lie. A bug fix will not fix a comment.
It is impossible to write perfectly clean code, but is very good to have a few sets of rules to help you manage an always growing application.
Surely it is not as important when you are a single developer or working on a very small team (2-3 people), but becomes increasingly important as your team grows.
this is so true
I don't know that I qualify as a 'professional' (I'm paid to manage computers and networks, not to code, but I still code a lot), but my thoughts on this are quite simple:
Have a well defined standard for both structure and formatting of code in your project that helps with readability for as many people as possible, and stick to it.
The issue is with the people who act like medieval crusaders regarding this type of thing, trying to force their specific ideals on others while not even considering listening to other people's resonans for why they do things differently.
Having a specific standard of coding is good
It helps as one learn new things, that's what CleanCode is all about(adopting the best practices)
I probably should have been a bit clearer, but what I meant was that it doesn't have to be the same standard as what CleanCode puts forth, as long as you have some standard that you're sticking to which doesn't make the code particularly hard to read.
I see far too many people getting hung up on a specific coding standard instead of just figuring out what works for their project, and as a result they spend lots of time jumping through hoops to meet the coding standard when their existing code was perfectly readable.
It's really difficult to write code that's clean. Even for those of us who've been in it for a while. That book seemed pretty good back when I read it, and it's fun to read, but honestly there's different techniques to focus on depending on where you are in the piece of code you're working on and the project in general.
Rather than 'clean' code, I tend to focus on making my code clear and making easy-to-understand abstractions.
You can follow advice like only writing necessary comments or limiting how many arguments functions take, and still end up with code that's fairly difficult to understand. I think the book goes into this as well, but thinking about software architecture and structuring your code well tends to have more of an impact on how understandable your code ends up I reckon. Stuff like creating clean abstractions, breaking your code it into logical sections and doing your best to make sure that every part does just what it's meant to, no more and no less. The good thing about this is that even if you're working with an existing codebase, knowing and actively thinking about this can still be really useful.
Most of the time when I start a coding project, I grab a pen and paper and just start drawing boxes and lines. What are the specific modules/sections of the code, what classes exist (the boxes), and what parts of the code talk to or use parts of each other (the lines). How many boxes need to exist so that you and other devs can clearly understand what each one contains at a glance, and how do you simplify communication across your code so that you have the least number of lines going between different boxes all over the place?
Or maybe you've got some other requirements, like how do I structure things to make it as easy as possible to add new managers/controllers/output formats/protocols -- every project's different, sometimes sacrificing how 'clean' the code is helps you achieve different goals. Even when you're not using objects at all, thinking about the different 'logical sections' of your code and how to design them can help a lot.
e.g.:
Software architecture in general and levels of abstraction are both good things to look into, working with different projects and seeing how they're designed is good for those. Looking into how to make your code easily unit-testable also does a lot of this work for you. The skills you use for this are really general, mostly just organising information into groups and displaying it as clearly and consistently as possible (e.g. graphic design, UI design, and even writing documentation relies pretty heavily on those skills), so they're also really transferable to other work you do around coding and tech.
Once you dive deeper into the writing-code side, the specific advice around stuff like simplifying inputs/outputs to functions, commenting well, and sticking to a consistent code style throughout your project become especially useful. Both are good sides to focus on
This was really helpful
Thanks for the insight 👍
I feel the post is more about this:
than what Clean Code strives for.
Simply put the cleanest of code is dumb, its simple, its tested and is obvious. Like other said, you need to put in time and effort to get to this sort of state.
The blog says:
That might be true until requirements change, or a bug is actually found, then you need to change your "good working code". If it isn't clean, or was done "just enough", you end up with a mess.
I could apply this idea to literally anything that isn't directly working toward requirements.
I followed this line of thinking I shouldn't refactor/test/use-better-tools/learn because it's not directly working toward the requirements.
Code is cleaned up over time only if it actually gets improved after every change. This task is made easier if the code is clean.
It seems to be the blog is addressing making code "beautiful and elegant", especially since it refers to functional programming, where code can end up extremely dense for the sake of elegance. Clean Code doesn't go down that route, it goes more the utilitarian route. (it also uses OOP code as examples)
Both are talking about "clean code", but both are really addressing different problems with different solutions, as such comparing them is kind of like comparing apples to oranges to a degree.
I don't think clean code is hard to achieve at all, the real challenge is keeping it clean over time. Requirements change, bugs are found and code needs to be refactored over-time to match those changes.
Yes from what I have learned so far from the book is that It mostly focus on the OO style of programming & as far as I know the functional approach is completely different.
I've read the Clean Code book and use it as a bible.
I think it is very practical and very useful.
What senior developers tend to forget is that their knowledge is very rarely teachable and easy to follow over time.
Clean code is. Also, it is super widespread in many different domains and that is a very powerful thing when talking about conventions and readability
Totally agree 🔥
I feel like poor management and morale is responsible for the ugliest code I have seen throughout my career. Clean code is all about consistency; as soon as most of the team is at the f*ck-it point, then everything tends to crumble really quickly. People may talk about fixing it later, but you're so glad to be done working on the dumpster fire of an application that it never happens. Consultants get brought in to fix the codebase and the process repeats, as they leave a bunch of half-assed kludges for the next development team to avoid for the next few months.
People need to be allowed to have a little pride in their code. Or at least I do. It's definitely a fine line, but if it feels like a punishment to be stuck in some crappy repository, the downward trend is likely to continue until it becomes abandonware.
There's a bit right near the end where Uncle Bob addresses this point. He points out that clean code is more effort than unclean code, and there's a trade-off. You shouldn't strive to make your code clean, you should strive for clean enough.
That and he also points out you can't write clean code. You have to write dirty code and clean it up using refactoring. Which is where Martin Fowler's book Refactoring comes in!
And heck yeah it matters, but it generally doesn't matter immediately. If you write a 250 line behemoth that doesn't explain a thing, with no tests, somebody else two years down the line is going to have to spend a day just working out what is going on. That person then has the choice to refactor or not. If the code was cleaned up at the time...
I'm on Clean Code right now. And the reason for it was simply an event that happened on my work. I left a few days because of a mission and one of my colleagues was in charge of implementing a feature. I could have done in almost one day, because I am familiar with that particular pieces of the code. But one week passed and the feature was half implemented. I asked myself why this happened and the answer for me was bad code and bad architecture.
The bad code made hard to my colleague understand what exactly was happening there. The bad architecture made hard to my colleague to understand where she had to make the changes.
So, Yes! Clean Code ALSO matters!
And remember that this is not the only book from Uncle Bob. He has another called Clean Architecture. So it is not the end of your journey to right better code.
Another experience that I had is pretty much what Uncle Bob describes in his book. We had a product where the code simply rot up to a point that it was not possible to add any other feature. If that were the main product of our company, we would be broken by now. Fortunately, it wasn't.
Our job isn't just solving a problem. If you are really professional, you will solve the problem on an economically, responsible and sustainable way.
It's good to know and adopt as part of your developer practice, just don't be too extreme to treat it as the only way or the highway.