Clean Code: It Does Really Spark Joy

Any fool can write code that a computer can understand. Good programmers write code that humans can understand.-Martin Fowler

What defines a cool programmer? Some say a cool programmer is a programmer that can create complex logic. Others say that a cool programmer is a programmer that creates CRUD applications in no time. Well for me, a cool programmer is a programmer that can create code that really sparks joy. That means the code that is created not only just functional or optimized, but also code must be readable & understandable by someone who didn’t even barely see the code before. If you want to achieve that, you can follow clean code principles.

Why do I Care About Clean Code?

However, not even anyone cares about your code because your code is just a bunch of clusterfucks.

It works functionally but it doesn’t sustainable as anyone doesn’t know what’s your app is doing so it becomes an abandoned application. What happened if this happens in a company context? There will be greater consequences more than just abandoned applications like loss of bucks, etc. You can check out this interesting real-world case that badly-written code could affect the development process https://www.quora.com/Game-developers-what-do-you-think-of-Yandere-simulator-Is-the-current-progress-in-6-years-understandable-due-to-it-being-developed-by-one-person. Many software projects involve not just a sole programmer, but many programmers and not just you that must understand what’s your code is doing, but others have to. That’s why clean code is important in order to make our software more continuable.

Code is clean if it can be understood easily — by everyone on the team. Clean code can be read and enhanced by a developer other than its original author. With understandability comes readability, changeability, extensibility and maintainability. — Robert C. Martin

Benefits of Clean Code in My Software Engineering Project

  • Ease the collaboration process & add positive vibes
  • Less time for code understanding
  • Make the code more reusable

A bit of my experience in this software engineering project, in the second sprint I got the task to create a CRU endpoint for “surat dakwaan”. The endpoint must be accessed only by authenticated users so there must be some kind of authenticated router that has authentication middleware that I can use. Fortunately, my friend has already created that one and name the router nicely so I can understand that router is indeed an authenticated router so I can just attach the dakwaan-related endpoints to that router. And now that’s what I called “spark joy”.

Clean Code Principle In Practice

One Function Only Serves One Responsibility

As you can see verifyDakwaan responsibility is just to make sure all the attributes are valid (terdakwa, alamat, pekerjaan, etc), no more and no less. The complexity of the attribute verification process is delegated to another function called verifyStringAttribute that checks whether a string attribute is valid or not. By doing this, if there’s some change in the attribute specification, we just modify the verifyStringAttribute. By doing this, the responsibility between is clear cut so we can determine easily which function should be improved or changed later.

Now let’s check a bad example that violates this principle. This snippet is taken from myPPW group assignment.

As you can see,that function is to summarize the order. Well the problem is that function does much more than just summarize the order, but it also processes the attribute, validates the attribute, etc. First, that function is too long to read since it doesn’t delegate other responsibilities. Second it harder to debug, because we don’t really focus on the summarization logic, but also the validation and stuff for that function.

Comment Only If It’s Really Necessary

You can see that method intuitively returns dakwaan entity with a specified ID from the database. Now compare with another bad example taken from my PPW group assignment.

That clearly violates the principle because if it’s wrong then fix it. Don’t comment on some bad or redundant codes.

Use One Word/Term to Represent One Concept

Be Consistent

Do Code Review

code review example in our project

Besides doing code review on merge request, we can also check the code quality by using linter (this should check whether the code is following good practice of a programming language) and sonarqube(this one is more detailed).

sonarqube review
linter job in gitlab ci

Minimize Code Duplication As Possible

Another tip is just to assign some repeatedly used to a function. Here is an example of that tips.

Notice that I created getMockDakwaanEntity() since dakwaan entity creation is repeatedly used by those unit test functions. Therefore I just create it as callable function to reduce code duplication.

Error Handling

Here on CreateDakwaan, we anticipate two kinds of possible errors. First when there are invalid attributes and second is when there’s an error in the entity creation on the database. As you can see the method return two kinds of output, the entity and the error. If the first case happened, it’ll throw an error that’ll say the corresponding attribute is invalid. Meanwhile, when the second case happens, the error from the database will be thrown as an error output.

One Test Function Should Cover Only One Case

As you can see those two tests test GetByDakwaanID function. The first covers the case when the corresponding dakwaan is successfully retrieved and the second covers the case when the corresponding dakwaan with the given id is failed to retrieve.

How Clean Code Really Changes My Mindset on Writing Code?

Clean code ain’t rocket science. It’s a habitual mindset, so you just need to get used to it

Conclusion

That’s all from me about clean code. I hope you enjoy this article and see you in the next article.

References

Bad Codes Sources