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.:
I'm writing a chatbot and there's a global manager, a database module, a user-account module, a display module, and a module that loads plugins, how do I make sure each module can talk to the modules it needs to without cross-linking absolutely everything to everything? Maybe an event-dispatch system that everything sends events through, maybe each module links the global manager as this.manager and routes everything through that, maybe just separating the app into two or more separate programs that communicate in a totally different way? How do I plan on extending the code in the future, and what's most important to me?
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
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 👍