Clean is a term that gets thrown around in the software development industry like null pointer exceptions. We read and hear everything about clean code(r), clean architecture and whatever other stuff that may or may not be clean in one way or another. Even project managers love to pick on us developers while rambling about the importance of this topic, often not being equipped with any coding experience or knowledge about it whatsoever.
So, it seems that over time many developers got desensitized to truly caring about these concepts which were meant to give structure and a sense of ease in our craftsmanship software development. Now let us take a step back together. Forget about the times this simple, silly word nearly made you lose your marbles and look at what it can truly do for us.
The main Benefits of Clean
As with everything a good amount of motivation makes things a lot easier. The main benefits of working clean are pretty obvious if you thought about it once.
- Easier to Test (more spaghetti for your dinner plate)
- Bugs are (more) obvious (again less spaghetti chaos in your code and problems sometimes just kind of resolve themselves)
- Lower maintenance burden (because there are less bugs to fix and customers to calm down)
- Less communication between developers needed (communication is key but let us use that time for more important topics)
And the list goes on. But you may already see a trend going in the direction of “If you do it right, you only have to do it once.”
Clean Code – everyone starts small
The devil is in the detail, so first focus on that one. Thinking of the actual essence of software brings us to the code itself. But let us not dive into classes just yet, what are characteristics your ideal code should have? What special kind of spice was in the last snippet you really liked just because of how it looked? Probably at least one of those features grabbed your attention:
- The code was documented, but not polluted by comments
- Names of variables and function seemed reasonable (not too long and not too short)
- The code was not nested in some (nasty) way
- Functions (if present) fit on your screen (without zooming out)
- Calls were not overflowing with parameters
Did you see your snippet? All these rather small things make a difference concerning the general appearance of your code. And guess what, with just those thoughts in mind, your code base will already make a huge step in the right direction.
Clean, simple, and smart.
Ps. I highly recommend all books written by Robert C. Martin if you are interested in cleaner code and a simpler developer life.
Cover image by Tatiana Syrikova on Pexels
(originally posted on dev.to)
Top comments (3)
Yes I agree that too much nesting is hard to test and reason about, rather refactor like split into functions.
Uncle Bob said to use 2 or at most 3 params for functions. It limits the number of combinations to test in unit tests, which grows exponentially for every param added. Also I like adding a structure as a param to keep things like. Pass an object of type Person which has 10 attributes, instead of 10 attributes. Where Person might be a class, or it could be a type of interface - typed languages like Go and adding types in Python and JS means you can pass a data structure to a function and be confident it has all the attributes set (while a plain dictionary without typechecking would be unreliable)
I haven't finished reading Clean Code... There are so many good coding books and so little time. But sometimes I feel I get stuck in analysis paralysis trying to make my code clean and functions only do one thing.
I feel like I start with Clean Coder intention and end with "I just need to finish this by the deadline"... I end up racking up a lot of technical debt. Future/Present day Tora is always cursing Past Tora for the swiping the Technical Debt credit card.
I do feel with experience, I have gotten better with writing clean code up front, but I always worry that things will get messy as deadlines get arbitrarily set for me.
Uncle Bob has a great blog and YouTube videos.
The only way to go fast, he is says, is to go well. ie clean coding
I am confused why you say in first bullet that clean code means more spaghetti rather than less spaghetti, and dinner space was unneeded. Also, grammatically it is fewer bugs, not less bugs.