YUK-RECYCLE’s Clean Code — A Myth ?
Hi, it’s Donny !
Some said a good software engineers not only considering whether their programs work or not, but have a spirit of software craftsmanship. What is that thing?
Uncle Bob with his book help us to know better about this. The summary you can read here.
Our team is always try to apply clean code on our code because our team thought that quality of a software is not only judged by its functionality, but also a quality code, maintainable, and secure.
This article is for you who want to applying clean code based on our experience.
Follow standard conventions.
Best example of this is naming a variable. Try to give a meaningful name to variable so your mate, or someone who continuing your code got no idea what is that variable.
What is a?? b?? This is why it called bad naming, because you have no idea what value stored in that variables.
You can see above, you have an idea what it is a second you saw it. You know title and body is needed to parse from a JSON.
Keep it simple stupid
Simpler is always better. Reduce complexity as much as possible.
The best example of this is a loop or iterations. We know that nested loop has a greater complexity so you have to make sure, if you can change your code to a single loop rather than nested loop, its better dude.
In Flutter case, you can use this idea in widget. if you can call out your widget from outside rather than nest it.
This is another example. We using routing instead of you import it from all of the class and then call it, because you don’t have to.
Boy scout rule.
Leave the campground cleaner than you found it. By ensuring that the campground is cleaner when they leave than it was when they arrived, they can guarantee that they are doing no harm, at least when it comes to the cleanliness of the site.
The Boy Scout Rule suggests an alternative approach, which is to simply try and ensure that with each commit, you leave the code better than you found it.
Always find root cause
It means, not only focusing on the line that problematic. But look at the bigger page. Sometimes, you only handle the error for that time only. But if there’s a bigger problem that you can handle, it’s better right?
The example like this one. You can actually code it in your code later on, but it will affect the whole code because not only you have to repeat yourself, you create more than one can be an error. Our case is, you have to always ask for authorization for everything you do.
Don’t repeat yourself
Closely related to KISS and the minimalist design philosophy. It states that every piece of knowledge (code, in this case) must have a single, unambiguous, authoritative representation within a system (codebase). Violations of DRY are referred to as WET: We Enjoy Typing, Write Everything Twice, Waste Everyone’s Time.
This is our example of don’t repeat yourself. The styling actually the same for all, so you can make it a styling at the top, the reuse it.
Conclusion
Our team implementation maybe not 100% using clean code, but we always try to implement clean code to our code. Cheers! *D*
