5 Tips for a Cleaner Code
Nowadays, the tech area has a huge dynamism and it means that developers are changing their current jobs more than ever.
Do we really write code to a machine? We should not forget that there are other people writing code in the same base source as ours.
There are a lot of opinions and structures that defines a code as a “good one”. It’s not necessary about the shortest code, but a better way to express what your code means.
All examples below were made on Ruby language
1. Naming Stuff
Why naming stuff matters? Imagine you are joining a new company and trying to discover what this piece of code in a movies context means:
Is it clear the intention of this piece of code? The only thing that we can assume is we are taking the first elements of an array, but what is this array? What does count mean?
What about this:
Better, right?
Naming things improves the communication between everyone who is coding in the same base source and as most explicit you are is better.
2. Improving Conditionals
We have some ways to improve the code conditionals, look at this:
Do you imagine a better way to do this switch case? It seems these values are supposed to be constants, so… What about this:
We translated the entire switch case into a hash, now it’s easier to understand.
The next one can save your life in many times, and it is recommended by Ruby Style Guides 😊
Have you ever heard about early return or guard clause?
“Hadouken If-Else” — MEME REFERENCE HERE:
When you put your eyes into this piece of code it’s hard to understand what is happening, isn’t it? Calm down, we can do it better:
The “Hadouken if-else” is over. All we did was splitting the cases into small pieces and ending the mess of the conditional decisions. It has a lot of benefits:
- It’s easier to maintain
- Avoids cognitive overload
- Improves readability
Believe me, if you try to improve conditionals, your life (and other’s) will be better
3. Error Handling
Error handling is important to make things work, if you don’t do this properly, if some exception raises it will be harder to understand what is happening in a certain context.
Imagine this situation, a critical notification to the context, what if some error occur in the HTTP request? In this case, it will raise some HTTP client exception (if the client deals with it) and will be hard to understand what is happening.
You should catch it and determine what you will do with the error:
💡 When you don’t specify the error in Ruby, it will rescue any error that extends StandardError class, for more information check the error hierarchy in Ruby
⚠️ Never rescue Exception, if you do it, all your system errors can be caught. The most specific your error is, the better to determine what you have to do, it’s your fallback.
4. Avoiding Unnecessary Comments
It seems to be simple, isn’t it? Some days ago I was coding in a legacy code and I came across the following:
Ok, now tell me… You know what C57 means? I spent a little time to realize that it means NOTHING 😅
In general, unnecessary comments can make confusion and time spent and nowadays, time is money…
5. Writing Better Tests
We all know that testing is a good thing, it can avoid a lot of bugs and can be a documentation complement.
What about writing better tests?
When I start writing some test I put on my mind that I need to be clear because a lot of developers will use this test to understand the application rules. So, I follow the Four-Phase Test Pattern:
Tests can be separated in four steps: Arrange, Act, Assert and Teardown.
Which can be summarized in: preparing everything for the test, stimulating what will be tested, verifying that the result is what was expected and cleaning everything that was done during that test.
💡 In Ruby, when we are doing transactions on database, the teardown occurs “automagically”, rollbacking every transaction in each final of the test
Example:
It’s easy to see every step of this unit test, splitting into minor pieces makes things less complicated.
Conclusion
These tips can guide you into your developer journey, your code will be cleaner and more important: will help other developers to understand your code.
And don’t forget:
Programmers must avoid leaving false clues that obscure the meaning of code.
— Robert C. Martin
Thanks for reading 🍻
