Improve your Code with Clean Code
What exactly is clean code? Does it mean you have to write code after you take a shower or clean your hands? Definitely not. As a professional programmer, we are not only concerned with how the software we make can work but also have a spirit of software craftsmanship. One of the important things of software craftmanship is how to write source code properly so that the software can be maintainable and easily developed for the long term.
Definition and Characteristics
First, you have to take a look at the definition and characteristics of clean code.
Clean code is a principle in programming that is needed to make programming better if implemented.
“Any fool can write code that a computer can understand. Good programmers write code that humans can understand. “
by Robert C. Martin
And after I read many sources on the internet, all of the views of clean code actually conical to this definition:
Clean code is code that is easy to understand and easy to change.
Yes, it’s easy to understand and easy to change, or the developer says is “easy to refactor”. Why does the code have to be easy to understand anyway? Because if the code is already messy and when our friend reads our code, they will be dizzy. So, we should not underestimate of clean code. Clean code itself can improve the quality of our code and make us a better programmer. You want to become better right? Good.
And here are the characteristics of clean code.
- Elegant. Clean code should be pleasing to read. Reading it should make you smile the way you tasting cheesecake for the first time or hearing music from the music box.
- Focus. Each function, class, and module exposes a single-minded attitude that remains entirely undistracted.
- Taken care of. Someone has taken the time to keep it simple, orderly, and cared so much about the code.
- Runs all the tests. We can not run from a bug that is in our code. Test-Driven Development is an excellent method to be applied. By conducting a test first, we ensure that our code passes certain benchmarks before use.
5. It contains no duplication.
6. Minimize the number of entities such as classes, methods, and functions.
There are some universal principles that can be applied to achieve clean code, including:
- KISS: Keep It Simple Stupid. This means that the code must be as simple as possible so that it is easily understood by others.
- Composition over inheritance. This means prioritizing composition over inheritance in OOP. With that, we focus more on the behavior of a class (composition) than the definition of that class (inheritance).
- Favor readability. This means prioritizing the readability of code because our code is not only read by machines, but also humans.
- Practice consistency. This means that if you write code in a certain way, stay consistent with it.
- DRY: Don’t Repeat Yourself. The meaning is to avoid doing the same thing many times. It can be difficult for us if we want the same thing to change.
- YAGNI: You Aren’t Gonna Need It. What this means is that we don’t need to create functionality that we think will be needed in the future, because it is better if the functionality is implemented when we just need it.
Implementation in BuildFocus
So now, have you wondering how to write clean code? okay, I will tell you some of the recipes for the implementation of clean code in my group at the software project course.
Before we jump to the implementation, first thing first is we refactor our code into many files and folders, to implement the clean code and make it easy to read. It will be very difficult for us to read a code consisting of hundreds of lines. This file is divided according to their functions.
- Meaningful names.
Choosing good names takes a lot of time but saves more than it takes. The name of a variable, function, method, or class, should answer all the big questions.
Method Names. Methods should have a verb or verb phrase names like deletePage, saveAccount, etc.
In my case, I use drawCircle to display a circle on the screen that extends CustomPainter. Lines 7 until lines 11 to make the specification of the circle, from color to style. Lines 14 until lines 17 to make the size and coordinate of the circle on the screen.
Class Names. Classes and objects should have nouns or noun phrases names like Customer, Addresses, etc. A class name should not be a verb.
This class is for showing a whole app in BuildFocus Application. In lines 10, we call the LandingPage in landing_page.dart as the first thing to see when the user uses the BuildFocus application.
2. Comments
Our code should explain everything. Don’t use a comment when you can use a well-named function or a variable. Brian W. Kernighan and P. J. Plaugher used to say
“Don’t comment bad code, rewrite it”
In Flutter, the comment appears automatically to indicate what widgets have been used, and this reflected in lines 148 until lines 153. This automatically comments help me to understand what does it for.
Efficient comments are used to explain code that cannot be interpreted in writing. In this example, I use the example comments that are written there .gitignore file. Lines 18 until lines 21 show us about the configuration and tasks that configure in VS Code before.
3. Functions
The function should do one thing only and do it really well. Make sure the function uses the concept of low coupling and high cohesion.
In this case, lines 39 until lines 46 stand for _handleTimeout() function. This function only handles time out of the stopwatch. The function does not handle any other function because we want this function to do one thing only, and that is to focus on handle time out.
Low coupling is the relationship between functions that should be reduced to be more dependent. This is intended to relieve the programmer if there is a change in one function, it will not have a big effect on other functions.
High cohesion is the interrelationship between methods that exist in a large function so that the function will be more effective, simple, and consistent. By applying this, dependencies on other functions are no longer needed so the programmer will automatically apply the low coupling properties.
4. Remove Unused Codes
As a programmer, we often make the code as a comment because we are just too insecure to delete the code. If this is done continuously, the programmer will find it difficult to delete the code that is not used if the code is very complex. Therefore, it’s best if it’s really not used, make it a habit to delete the code, but if you feel you still want to use it, you can move the code to another file so that the overall code will look easier to read.
Lesson Learned in BuildFocus
Clean code is not something you can learn in one single day. I myself need 3 years to learn and implemented the clean code from many sources. If you feel your code is unreadable or you do not understand about what you already wrote, that is the time you have to start cleaning your code IMMEDIATELY! Start by properly naming your variables, methods, class, and functions. Those will make your code more readable and set you on the right path.
The lesson learned I got when implemented clean code in BuildFocus are :
- Simplicity
We enjoy it working in a clean codebase rather than in a messy codebase. This happens because we always keep our code as simple and readable as possible. By keeping it simple, we can produce higher quality code, solve problems faster, and work better as groups which makes us happy every time we code. - Easier to Test
By building clean code, automated testing of that code is encouraged. Automated testing, also known as Test-Driven Development can improve the long-term velocity of a team, and reduce the number of software defects. - Easier to understand
The production code that we wrote has to readable so the other fellas can understand what the code stands for. We, as a team, always make the code is clean, start with meaningful names, remove unused comment and code, make an effective comment, and always create functions that only do one thing. Who knows in the future I might revisit the code and thanks to clean code, I still understand what the code is trying to explain for. - Bugs are Obvious
Clean code can make the presence of bugs is more obvious. This allows us to get better feedback during code review since mistakes of reasoning will not be obscured by unnecessary complexity. - Easier to Refactor
We have done writing code in the first sprint and for some cases, in the next sprint, we want to refactor our code from the first sprint. We don’t want to spend much time on the project because we need to understand the code we wrote before, so clean code can make this problem go away in just one snap.
I totally understand that it’s hard to write good code. But till how long you’ll delay making that thing happen? Start slow and be consistent. Though it has taken some hours of our daily time, believe me, it will pay in the future. You have my word :)
See you in another blog!
