Understanding Clean Code in Android

Tram Ho

As Uncle Bob said in his books,

You are reading this “article” for two reasons. First, you are a programmer. Second, you want to be a better programmer. – Robert C. Martin

Imagine, you are in a library, and you are looking for a few books at the end, If the library is clearly arranged and categorized, you will quickly find the book you want. In addition, the library space (design and architecture) will make you feel comfortable while looking for books.

Just like writing a book, if you want to “build” something “great”, you need to know how to write and organize your code. And if you have a team member or someone with the same teamwork, they need to know the variable names or packages or classes name and understand them correctly. They also won’t need to say “DCM – code like cc” and start coding again from zero

What is “Clean Code”?

As everyone knows, it is not good enough to just code fast that others cannot understand your code, because it will become a mess later (for others and yourself).

The code is defined as “Clean” when it can be easily understood by all team members. Code can be read and improved by other developers (besides author).

In short, “Clean code” is easy to understand code. With the accompanying understandability is easy to read, change, expand and maintain.

So is it necessary? The answer is yes ! Your code will describe your thought process to others. That’s why you have to start thinking about making your code simpler and more readable.

The criteria of the Clean Code

  • Code must be “Elegant”: Your code must be used in a simple, light and correct manner in the way it is used. The writing style must be even, just like other lines of code in a project!
  • Code to be taken care of: Caring here means you have to really pay attention to each line of code. Every use of code, every character has to be optimized.
  • Code must be specific: Each function, class, module performs a unique task and is not affected by other factors.
  • Code is not duplication
  • Pass the test
  • Minimum use of classes, methods, functions

One difference between a smart programmer and a professional programmer is that the professional understands that clarity is king. Professionals use their powers for good and write code that others can understand. – Robert C. Martin

Create meaningful Variable Names

Setting a good name is time consuming, but it will be a lot less time consuming to read and extend the code. The name of the variable, function, or class will answer the question itself. Like why it needs to exist, what it does and how it is used. If one knows it needs a comment to answer these questions, it is a “bad name”!

For example :

– Class Names

Classes and objects should have noun names or phrase phrases such as Customer, WikiPage, Account, AddressParser. Avoid using verbs for classes and objects.

– Method Names

Unlike classes and objects, Methods should be named verbs or verb phrases like postPayment, deletePage, or save. Accessors, mutators. The predicates must be named for their values ​​and prefixed with get, set and javabean.

– Use Problem Domain Names

Use the domain with the meaning of the work it undertakes. At least to the programmer – who will brief your project can understand what it is!

Write code according to SOLID principle

SOLID is a set of rules for code in the most clean way. Let’s take a walk!

Single Responsibility Principle – SRP

Simply put, each class only undertakes a single task. There should never be more than one reason for a Class to change. If a class has more than one task, break it up into smaller classes to perform separate tasks!

For example: You have RecyclerView.Adapter with business logic in onBindViewHolder .

This makes the RecyclerView.Adapter not guarantee the principle of only one task because the business logic is in onBindViewHolder. This method should only set data for setting data.

Open-Closed Principle – OCP

Entities should open for extension but closed for modification . That is, if you write Class A and then another member wants to modify a function in Class A, then they easily extend Class A, instead of directly editing this class.

A simple example is the RecyclerView.Adapter class. You can easily extend the class and create custom adapters with the custom behavior you want and without having to modify the available RecyclerView.Adapter Class.

Liskov Substitutions Principle – LSP

Child classes should never break the parent class’ type definitions.

This means that subclasses will override methods from the parent class without breaking the function from the parent class. For example, you create an interface class that has an onClick () listener, and you must apply it to MyActivity and have an additional Toast action when onClick

** Interface Segregation Principle – ISP **

The interface-segregation principle (ISP) states that no client should be forced to depend on methods it does not use.

If you create class A and implement it into another class (for example, class B), there is no need to override the entire class A methods into class B. For example, in the activity, you want to implement the SearchView.OnQueryTextListener () and just the onQuerySubmit () method.

So how to do the above? You simply need to add a callback!

** Dependency Inversion Principle – DIP **

Depend on Abstractions. Do not depend on concretions.

There are 2 points to note:

  • High-level modules should not depend on low-level modules. Both should depend on abstractions.
  • Abstractions should not depend on details. Details should depend on abstractions.

High-level modules, providing complex logic, can be easily reused and unaffected by changes in low-level modules, providing utility features. , you need to bring out an abstraction that separates high-level and low-level modules from each other.

An easy to understand example is that in the MVP pattern, you have an interface object that helps us communicate with specific classes. What that means, UI classes (Activity / Fragment) don’t need to know how to actually implement methods in Presenter. So if you have any changes inside the Presenter, UI classes do not need to know or care about the changes.

For example: UserPresenter.kt

UserActivity.kt

Conclusion

Hopefully through this article, everyone has more knowledge and understanding of clean code. Hopefully in the future, the code will always Clean to make me more professional!

Source: https://medium.com/mindorks/understanding-clean-code-in-android-ebe42ad89a99

Share the news now

Source : Viblo