Same with bakery, clean code doesn't means that you need to have no duplicates, solid, etc. You can work with dirty codes, until it gets too dirty to work on and you need to start cleaning, by which will takes considerable of time. Otherwise if you want to make it as clean and spotless as possible, it'll take considerable time and also you need to do that every time changes applies.
Consider renovation projects, you won't see they mop the floor everyday to the spotless level, they'll maybe sweep and clean it to the point where it's acceptable to operate. As you get better and with better tools, you can make less mess and less, but there'll be trash somewhere.
And same in code, you clean your code to an acceptable level, otherwise the code will be too dirty over time and hard to be worked on, and as you get better you'll make less dirty code. Problem is, nobody can know / agree on the acceptable level in programming which makes things hard.
EDIT: Got confused and wrote about Clean Architecture instead.
In my first year of professional programming, I tried to apply Clean Code to a side project. What I learned is exactly what you wrote. The result is very modular, but it’s a lot of code to write. But these are good ideas. What I needed to do was to develop my own philosphy and then to adapt it to the project’s context.
It’s the same with DDD. Which globally give the same guidelines: The use cases should drive your design; Push technical considerations out of the domain model; Cluster things that belongs together;…
But all of these is to balance speed (now), readability (near future), and maintainability (far future). These techniques and others will help you discern the equilibrium (which varies during the software lifetime)
Robert Martin and John Ousterhout have a conversation about Clean Code[0] versus the approach in A Philosophy of Software Design.
> Clean Code repeatedly gives very strong advice in one direction without correspondingly strong advice in the other direction or any meaningful guidance about how to recognize when you have gone too far.
My take is that that Clean Code has some good advice for enterprise style software projects. It is incredibly prescriptive but sometimes that's not such a bad thing. In my experience it's worth it in uncoordinated/inexperienced teams who would otherwise produce an undisciplined mess of code.
Stick with it if it works for you as long as you don't go around bashing other people for not doing it the "right" way as many clean coders do. The dogma surrounding what amounts to a set of preferences and design trade-offs is what makes Clean Code so off-putting, especially if you have slightly different preferences.
No. If you're doing it right, it shouldn't take much extra time, and it will make your code much more readable and maintainable.
A lot of the "work" is automated these days anyway. Mainstream languages have hinters/linters or static analyzers that will catch many of these issues, and some (like TypeScript) have incredibly powerful static analyzers that will fix the issues automatically when they can.
You are not supposed to treat it as a gospel, following every guideline. Instead, it is a collection of ideas presented to you, so that you can decide if you want to use them (or not!) in your day-to-day work.
In general, software development is not a profession where you learn how to do things and do them, occasionally refreshing your skills. It is a perpetual problem solving field (not without its routines), and a continuous journey. Creativity, personal opinions and exchange of ideas play an integral role in this profession.
I like a lot of Muratori’s writing but… is it really wise to take code architecture tips from game devs, of all people? I’m willing to trade lots of performance in exchange of extensibility and stability over the long term.
I’m not a huge fan of overwrought OOP either, but modeling everything with scalars and comments makes it sometimes harder to add new behaviours.
I’m also not a fan of video content, here is a transcript of the above video,
If you look at the “not clean” code in the above, it’s fine, it’s still relatively easy to follow etc. Now think about extending it so that some shapes are the result of summing multiple sub-shapes, like a general polygon tiled out of triangles. That’s straightforward in the OOP case, but not so much in the flattened array case, and means that we need to reintroduce pointer indirections if we don’t want our shape union to be as large as our biggest shape etc. (I still might use a switch statement over inheritance.)
Few books are truly a total waste of time, and reading often has benefits even when you disagree with the author. But once you put all caveats aside: yes, yes it is
Business will always take precedence. I don't like it, never have, but if you have to decide between writting well documented code and code making money, always choose the latter.
Good companies will recognise that this should be a balance and provide their developers enough time to do both to a satisfactory degree. Sometimes the devs will have to push for this, and will meet resistance, but as with everything in engineering, nothing is black and white.
Write the best code you can, under the circumstances you can. It's a delicate balance.
Yes, however there’s circumstances for when it’s most effective. For example:
Large systems benefit from clear architectural patterns, whereas small systems see little benefit
Performant code is often obscure and messy, it shouldn’t be forced into a “clean pattern” for the sake of it
Clean architecture greatly affects how changes are made in the system. If 20 places need to be updated to add a feature, and that’s something that needs to be done often, then maybe refactoring it would improve this workflow.
At the end of the day it’s a tradeoff that programmers need to make
“will cleaning this up make it better or worse for us”
What I learned while working at startups is the actual worst thing you can do with code is create smell.
Code smell.
If it worked and passed the “clean” test but still didn’t scratch an ego or worse, did something ypir peers or boss didn’t think of as a solution, then it would “smell”.
I would have thought only “unclean” code could “smell” but even the “cleanest” code could “smell”.
It made work as rigorous as shooting an arrow in the dark. But the shame of smelly code would have brought the whole thing to its knees so I am relieved such pertinent problems are being so addressed so aggressively by the truly smartest of humanity.
Practically, if a PR comes in and it's either a one-shot script or something small, I wouldn't bother too much about anything as long as it works and doesn't smell really bad (e.g. every variable is of single character).
But it's another story if 1) the code is entangled with business logic, or 2) it's part of a medium-large project. In case of those I'd demand very detailed documentation and passing some linter at least.
* The total time it takes to perform a large refactor. This should take no more than 4 hours, 2 ideally, to code and qualify with high confidence using test automation.
* Speed of code style enforcement. If it takes more than 1 minute total effort to impose a code style evaluation (including human time) then it is wrong, even for a very long application.
Clean Code and many others methodologys were valuable on a time where code was built to last.
Today codebases are being constantly rewritten, sometimes from scratch, using wherever language or framework of the moment.
it.
And I'm not even talking about LLM generated code, there is no such thing as clean code for them
The 20,000 line function causes code (entire products) to be thrown out. Watching it happen right now. Huge cost.
Things like this happen because a group of offshore devs with two years of experience each were granted the responsibility of developing software without technical leadership. Had someone sat them down for five minutes and explained clean code and guided them through it for a month, it never would have happened.
Yes and No. It is way over hyped and sold to the younger generation as some sort of "revelation". It is nothing of that sort but merely some good opinions undeservedly generalized as truth. So read a lot of books and come up with your own approach based on your own experience and studies.
Honestly, if you are a small/medium startup, just having things like:
1) Eslint (any comprehensive linter)
2) Clear enough instructions (or a framework) on where different parts of the application should go
3) Clear instructions on how the branches should be handled and merged
4) CI/CD on Pull Requests
5) Comprehensive tests on the core business logic (mostly on the backend).
6) Maybe some regression tests just to make sure that nothing on the frontend breaks
All pretty standard stuff, and you can set it up in a day, a lot of the boring work can be done by LLMs, so you won't have to waste a lot of time on it.
I find that just doing the above things gives a project enough stability, and it gives the developers enough courage to refactor with confidence and ship relatively fast.
At the end of the day Software Architecture is a craft, if a system is not working for you or your team (or you don't understand why you are doing something), then you want to look at changing it.
I currently work on a ~10+ year old project that has maybe half of this list, and if you _don't_ start this way, the toothpaste is near impossible to put back in the tube, and you're in for a world of hurt. If the early engineers don't work this way and the system makes its' way into production, then functional software + income is very difficult to override in the name of cleaning up messes.
The problem with Clean Code and other architecture porn methodologies, is that they work until they don't. You might follow clean code, until a new teammate comes and he/she has their own opinions about your code, your architecture, or even your choice of framework.
I have a strong feeling is that architecture methodologies work as long as you are a very small and super committed team (see: startup where you all are invested into the success of the product), but they shatter to parts in a bigger corporate environment where acquisitions, mergers, and rewrites happen every other month, and you need to adopt the new framework/language/methodology/scrum/kanban/whatever.
This principle is baked into every decent SAST tool. Huge, successful and very competent software-based companies are using SAST in the pipeline to enforce this.
I don't agree on Joel for everything but his bakery clean analogy https://www.joelonsoftware.com/2005/05/11/making-wrong-code-... feel spot on for me.
Same with bakery, clean code doesn't means that you need to have no duplicates, solid, etc. You can work with dirty codes, until it gets too dirty to work on and you need to start cleaning, by which will takes considerable of time. Otherwise if you want to make it as clean and spotless as possible, it'll take considerable time and also you need to do that every time changes applies.
Consider renovation projects, you won't see they mop the floor everyday to the spotless level, they'll maybe sweep and clean it to the point where it's acceptable to operate. As you get better and with better tools, you can make less mess and less, but there'll be trash somewhere.
And same in code, you clean your code to an acceptable level, otherwise the code will be too dirty over time and hard to be worked on, and as you get better you'll make less dirty code. Problem is, nobody can know / agree on the acceptable level in programming which makes things hard.
EDIT: Got confused and wrote about Clean Architecture instead.
In my first year of professional programming, I tried to apply Clean Code to a side project. What I learned is exactly what you wrote. The result is very modular, but it’s a lot of code to write. But these are good ideas. What I needed to do was to develop my own philosphy and then to adapt it to the project’s context.
It’s the same with DDD. Which globally give the same guidelines: The use cases should drive your design; Push technical considerations out of the domain model; Cluster things that belongs together;…
But all of these is to balance speed (now), readability (near future), and maintainability (far future). These techniques and others will help you discern the equilibrium (which varies during the software lifetime)
Robert Martin and John Ousterhout have a conversation about Clean Code[0] versus the approach in A Philosophy of Software Design.
> Clean Code repeatedly gives very strong advice in one direction without correspondingly strong advice in the other direction or any meaningful guidance about how to recognize when you have gone too far.
My take is that that Clean Code has some good advice for enterprise style software projects. It is incredibly prescriptive but sometimes that's not such a bad thing. In my experience it's worth it in uncoordinated/inexperienced teams who would otherwise produce an undisciplined mess of code.
Stick with it if it works for you as long as you don't go around bashing other people for not doing it the "right" way as many clean coders do. The dogma surrounding what amounts to a set of preferences and design trade-offs is what makes Clean Code so off-putting, especially if you have slightly different preferences.
[0] - https://github.com/johnousterhout/aposd-vs-clean-code/blob/m...
No. If you're doing it right, it shouldn't take much extra time, and it will make your code much more readable and maintainable.
A lot of the "work" is automated these days anyway. Mainstream languages have hinters/linters or static analyzers that will catch many of these issues, and some (like TypeScript) have incredibly powerful static analyzers that will fix the issues automatically when they can.
Cheat sheet on Clean Code: https://gist.github.com/wojteklu/73c6914cc446146b8b533c0988c...
You are not supposed to treat it as a gospel, following every guideline. Instead, it is a collection of ideas presented to you, so that you can decide if you want to use them (or not!) in your day-to-day work.
In general, software development is not a profession where you learn how to do things and do them, occasionally refreshing your skills. It is a perpetual problem solving field (not without its routines), and a continuous journey. Creativity, personal opinions and exchange of ideas play an integral role in this profession.
You may enjoy “"Clean" Code, Horrible Performance”, from Casey Muratori.
https://www.youtube.com/watch?v=tD5NrevFtbU
Casey specialises in game engine research and development
https://caseymuratori.com/about
And has an ongoing course on computer performance for programmers.
https://www.computerenhance.com/
I like a lot of Muratori’s writing but… is it really wise to take code architecture tips from game devs, of all people? I’m willing to trade lots of performance in exchange of extensibility and stability over the long term.
I’m not a huge fan of overwrought OOP either, but modeling everything with scalars and comments makes it sometimes harder to add new behaviours.
I’m also not a fan of video content, here is a transcript of the above video,
https://www.computerenhance.com/p/clean-code-horrible-perfor...
If you look at the “not clean” code in the above, it’s fine, it’s still relatively easy to follow etc. Now think about extending it so that some shapes are the result of summing multiple sub-shapes, like a general polygon tiled out of triangles. That’s straightforward in the OOP case, but not so much in the flattened array case, and means that we need to reintroduce pointer indirections if we don’t want our shape union to be as large as our biggest shape etc. (I still might use a switch statement over inheritance.)
Way to start a Friday argument :-D
FWIW - no it's not an absolute waste of time. But, it's arguably more dogmatic than is realistic for most teams.
And I would say it's certainly not required for an elegant readable and high quality codebase. But it has ideas which are worth absorbing.
Yes
Few books are truly a total waste of time, and reading often has benefits even when you disagree with the author. But once you put all caveats aside: yes, yes it is
Business will always take precedence. I don't like it, never have, but if you have to decide between writting well documented code and code making money, always choose the latter.
Good companies will recognise that this should be a balance and provide their developers enough time to do both to a satisfactory degree. Sometimes the devs will have to push for this, and will meet resistance, but as with everything in engineering, nothing is black and white.
Write the best code you can, under the circumstances you can. It's a delicate balance.
If you are petitioning people to let you develop clean code the fight is already lost. It's just something you do as part of making the sausage.
Yes, however there’s circumstances for when it’s most effective. For example:
Large systems benefit from clear architectural patterns, whereas small systems see little benefit
Performant code is often obscure and messy, it shouldn’t be forced into a “clean pattern” for the sake of it
Clean architecture greatly affects how changes are made in the system. If 20 places need to be updated to add a feature, and that’s something that needs to be done often, then maybe refactoring it would improve this workflow.
At the end of the day it’s a tradeoff that programmers need to make
“will cleaning this up make it better or worse for us”
What I learned while working at startups is the actual worst thing you can do with code is create smell.
Code smell.
If it worked and passed the “clean” test but still didn’t scratch an ego or worse, did something ypir peers or boss didn’t think of as a solution, then it would “smell”.
I would have thought only “unclean” code could “smell” but even the “cleanest” code could “smell”.
It made work as rigorous as shooting an arrow in the dark. But the shame of smelly code would have brought the whole thing to its knees so I am relieved such pertinent problems are being so addressed so aggressively by the truly smartest of humanity.
Logic issues? That’s okay. Code smell? GTFO
It's a very broad question.
Practically, if a PR comes in and it's either a one-shot script or something small, I wouldn't bother too much about anything as long as it works and doesn't smell really bad (e.g. every variable is of single character).
But it's another story if 1) the code is entangled with business logic, or 2) it's part of a medium-large project. In case of those I'd demand very detailed documentation and passing some linter at least.
For me clean code means exactly two things:
* The total time it takes to perform a large refactor. This should take no more than 4 hours, 2 ideally, to code and qualify with high confidence using test automation.
* Speed of code style enforcement. If it takes more than 1 minute total effort to impose a code style evaluation (including human time) then it is wrong, even for a very long application.
Clean Code and many others methodologys were valuable on a time where code was built to last. Today codebases are being constantly rewritten, sometimes from scratch, using wherever language or framework of the moment. it. And I'm not even talking about LLM generated code, there is no such thing as clean code for them
The 20,000 line function causes code (entire products) to be thrown out. Watching it happen right now. Huge cost.
Things like this happen because a group of offshore devs with two years of experience each were granted the responsibility of developing software without technical leadership. Had someone sat them down for five minutes and explained clean code and guided them through it for a month, it never would have happened.
> 20,000 line function ...? Is this an actual figure
I've seen similar, thousands up to about 10k, but never 20k myself. It would not surprise me to find it in the wild, though.
Yes and No. It is way over hyped and sold to the younger generation as some sort of "revelation". It is nothing of that sort but merely some good opinions undeservedly generalized as truth. So read a lot of books and come up with your own approach based on your own experience and studies.
Yes, if your code is worthless and no one (including yourself) will read it again.
Honestly, just keep your code layered and use single responsibility principle.
Every function should do only ONE thing. Use layers to separate concerns, and again, each function in each layer should do ONE thing.
After that, go wild.
Maybe Clean Code, but not modular code. Modular Code makes it easy for AI to make your life even easier
No, saves a lot of time if you know how to skim it correctly.
Yes
Honestly, if you are a small/medium startup, just having things like: 1) Eslint (any comprehensive linter) 2) Clear enough instructions (or a framework) on where different parts of the application should go 3) Clear instructions on how the branches should be handled and merged 4) CI/CD on Pull Requests 5) Comprehensive tests on the core business logic (mostly on the backend). 6) Maybe some regression tests just to make sure that nothing on the frontend breaks
All pretty standard stuff, and you can set it up in a day, a lot of the boring work can be done by LLMs, so you won't have to waste a lot of time on it.
I find that just doing the above things gives a project enough stability, and it gives the developers enough courage to refactor with confidence and ship relatively fast.
At the end of the day Software Architecture is a craft, if a system is not working for you or your team (or you don't understand why you are doing something), then you want to look at changing it.
I currently work on a ~10+ year old project that has maybe half of this list, and if you _don't_ start this way, the toothpaste is near impossible to put back in the tube, and you're in for a world of hurt. If the early engineers don't work this way and the system makes its' way into production, then functional software + income is very difficult to override in the name of cleaning up messes.
Yes
[dead]
Never read his books. But I found good architectures is very helpful for LLM-assisted coding, if I keep things nicely named and decoupled.
The problem with Clean Code and other architecture porn methodologies, is that they work until they don't. You might follow clean code, until a new teammate comes and he/she has their own opinions about your code, your architecture, or even your choice of framework.
I have a strong feeling is that architecture methodologies work as long as you are a very small and super committed team (see: startup where you all are invested into the success of the product), but they shatter to parts in a bigger corporate environment where acquisitions, mergers, and rewrites happen every other month, and you need to adopt the new framework/language/methodology/scrum/kanban/whatever.
This principle is baked into every decent SAST tool. Huge, successful and very competent software-based companies are using SAST in the pipeline to enforce this.