In this article, I’m going to talk about writing clean code in general and then end up with some examples. As an Android developer having a clean code has always been challenging for me which needs lots of effort and that’s just coding and coding.
Rules We Should Follow
- Ignore duplication (imply DRY principle-Don’t Repeat Yourself)
- Minimize entities, classes, and functions (avoid repetition)
- It should be readable and simple
- Be testable as it makes your code flexible and maintainable
- Follow SOLIDprinciples
S = Single-responsibility principle: A class should only have one purpose.
O = Open-closed principle: A class should be open for extension, but closed for modification.
L = Liskov substitution principle: Abstraction should be able to provide all needs of child class.
I = Interface segregation principle: Small interface is better than big one.
D = Dependency Inversion Principle: A class should depend on abstraction, not implementation.
6. Be careful with dependencies
As many as possible try to have one-directional dependency. When dependency goes in multiple directions, things get much more complicated which makes hard to update and change.
7. Don’t hardcode
Define constant or use variables instead of hardcoding the values which will not only help readability but also make it easy to change if it is being used at multiple places.
Now let’s start writing Clean Code 🚀 …
Naming is one of the hardest parts of programming and may take time to choose, but it is a strong way to convey your code’s intent to other developers who read them in the future which must show the purpose of that class, function, or variable and even tell what is going to do. Don’t append prefixes or type information. I always have a checklist in my mind as listed below which assures me that a name has been chosen well:
- Are the variables named according to the convention (camelCase, PascalCase, etc)?.
- Does the name have an appropriate length to ensure that no one will be confused by it?.
- Are the name of variables clear about what they hold?.
- Are the names meaningful, searchable, and easy to pronounce?.
Class names should not only be names (not verbs) but also should have the PascalCase convention. On the other hand, method names should be verbs or phrase verbs and follow the camelCase convention. The same rules apply to variable names.
Functions and Methods
Following S from SOLID principles, let functions and methods perform only one task which should be small. If the function arguments are too many, you should review your code and maybe pack them into an object or divide that task between some other functions. Prefer possible exceptions to return error codes and extract error handling
try catch into their own function.
We should use comments only when it is necessary, not to explain bad code. Writing lengthy comments will not help us in changing our code into a clean one. If the code is bad, we should solve it by improving the code, not by adding instructions on how to use it, but it doesn’t mean that you shouldn’t use comments at all, sometimes it is important such as dealing with third party APIs where you need to explain some behavior.
It might look unimportant at first glance, but it is of high importance to write your code with a well-organized format which makes it readable such as:
- Do not write everything in a single line. Give proper whitespace, indentation, or line breaks in your code.
Indentation styles assist in identifying control flow and blocks of code. In some programming languages, indentation is used to delimit logical blocks of code; correct indentation in these cases is more than a matter of style. In other languages, indentation and white space do not affect function, although logical and consistent indentation makes code more readable. (Inspired by WIKIPEDIA)
- Instance variables should be declared at the top of the class.
- If functions are calling each other (dependent functions) they should be close while putting the caller at first.
- It is often helpful to align similar elements vertically, to make typo-generated bugs more obvious.
The importance of Test code is equal to producing the code and of course, while writing tests you might find some bugs. However, it can sometimes be quite difficult to write a good test for a particular piece of code which is a result of a badly designed and untestable code. Testing is almost like coding for the second time so follow all the previous rules for writing a good test as well which should be as per below :
- One assert and single concept per test
- Easy to write and readable (simplicity)
To conclude, I hope this article could be helpful to write a better code although it is important to keep practicing and learning in this field 😃 …