Clean Code

Cleaning up!

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.

stockLocation naming convention

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.

Using comments in practice

The comment Id is set as natural number, -1 will always be wrong idis 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.

Error Handling in Moodah POS

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.

Throwing errors GraphQL Playground

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

Before and after refactoring

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.