Clean Code
Being a good programmer also mean being a programmer that knows how to make codes that is easily read by others. In other words, we must follow conventions that we agree on in order to create a consistent code flow.
“Clean code always looks like it was written by someone who cares.”
— Michael Feathers
Applying Clean Code
There are a lot of ways you can implement clean code. Here I will show common principles in applying clean code, as well as my experience with it
DRY (Do not Repeat Yourself)
In many cases, we tend to copy paste codes that is working. Well, DRY says otherwise. By not repeating yourself, your codes will become more defined and easier to track down.
As an example, I keep using GET_POS_CONFIGS
instead of copy pasting the same query so that my team members and I can easily track down how i run my tests.
Naming conventions that is readable by others
In order to be more consistent as a team, we need to be able to create variable names that explains what they are doing. With proper naming, there will be better understanding on how the code works across the team.
As an example, result.length === 0
and rej()
explains that the logarithm will rejects if the result array has nothing in it. In addition, the function and variable namenew ApolloError
, errorMessage: result.message
explains that error will be send, even without us knowing how it will work. This ease us in learning the code.
Comments for Clarification
There are some cases where your codes are hard to understand, even with proper naming. Using comments will help a lot in order to maintain a clear understanding on hardly defined codes.
The comment Id is set as natural number, -1 will always be wrong id
is placed just in case when others lack the knowledge that id is always positive. The const WRONG_ID = -1
might not explain well in this case, thus there is the need of comments.
Using Library
There are a lot of libraries you can find that help in creating cleaner codes. From my experience, I am told that all of the variables should be camel cased in order to match the naming conventions. Using humps
, I can do that easily, even with trickier objects.
ESLint, a linter that helps and covers your code styling, is used so that our team is consistent in programming our codes. With this, we can ensures that our style remains prettified and consistent.
Error Handling and Exception
Error is a unwanted faulty, we don’t want that to appear in our program. As a software developer, we must be able to handle these errors without diminishing the program’s readability. To show better on how error handling works, below will be an example of error handling in Moodah POS inside our GraphQL query and mutation function.
In each of our Apollo GraphQL functions, we checks for error and rejects them using the standard ApolloError
convention. This way, the error/exception handling can have a better readability, since we can look for the ApolloError
documentation as to how the code flow works.
Now that we have our error handling, we don’t need to worry if there is a wrong GraphQL implementation (hopefully), since faulty is caught right away. In Moodah POS’ query, giving out a negative index of a records will yield error, and the errorMessage
tells you clearly of what you have done wrong.
File and Folder Structure
To create a clean environment, we need to make sure that codes that has different functionality not be in the same files and folder. Thus, we separate files that interacts with different models, into different folders. This helps in keeping our sanity, since we don’t need to search through the file lists anymore.
In addition, we are also separating our schema files, which was where all our functions are set. After refactoring, we now have smaller “schema” files called the index files, which is placed in each “model function” folder, and a single main index. This way, our main index will not have thousands of line codes anymore! Pretty clean if you ask me~
Conclusion
“You know you are working on clean code when each routine you read turns out to be pretty much what you expected. You can call it beautiful code when the code also makes it look like the language was made for the problem.”
— Ward Cunningham
As we strive to develop better programs, it remains important to keep our codes clean. Being a good developer also means being able to create codes that is readable and scale-able.