Clean Code
What is “clean code”? While readability might be the first thought when answering this question, it is also important to understand that clean code is also easily understandable and easily modified. In Mfonido Mark’s article “Writing Clean Code: Best Practices and Principles,” (https://dev.to/favourmark05/writing-clean-code-best-practices-and-principles-3amh) some of these principals are outlined. Mark also outlines the benefits of writing clean code, which can include increased readability, increased maintainability, better opportunities for collaboration, reduction in bugs, and increased efficiency.
Mark goes on to identify a number of practices that promote clean code and foster the benefits of writing clean code. While we (as developers) often like to think that our code falls into the category of “clean”, it’s also important to be critical of our own coding styles and work to adhere to best practice standards in order to facilitate a more efficient and product professional environment. After having read Mark’s article, I reflected on some of these practices and saw room for improvement in my own coding practices. Moving forward, there are a few of these clean code practices that I realized I could improve upon:
- Keeping Methods and Functions Short
- My own style often puts too much into a single method or function – after all, “calculate_price()” should be calculating the entire price, right?!
- Realistically, a function like calculate “calculate_price()” should depend on getting the totals of the user’s items, calculating the total, applying discounts, calculating the tax, and adding all of those numbers together.
- Having functions like this more modularized allows for much easier collaboration and modification in the future. If the sales tax changes at some point in the future, or how sales are taxed is changed, it becomes much easier to make that modification without affecting any other entities.
- Using Comments and Documentation
- I am notorious for “over-commenting” my code. While I don’t comment every single line, I do often create a pretty granular overview of what exactly my code is doing.
- Mark’s article points out that your code should be self-explanatory rather than heavily commented, but that comments should still be used for complex algorithms and decisions and public APIs.
Again, without this period of self-reflection, I likely would have continued coding in a way that doesn’t quite align with “clean code” best practices. And in turn, I would have continued to produce code that was not as readable, understandable, or modifiable as it could have been. By taking these tips into consideration, I am able to be more effective as a professional and as a developer.
Code Smells
In Georgina McFadyen’s article “Common Code Smells” (https://8thlight.com/insights/common-code-smells), McFadyen explains that developers often get caught up in creating sound logic and handling of things like edge cases. However, as McFadyen points out, that often leaves much to be desired when thinking about maintainability and other issues that don’t change the essence of how the system works. Code Smells should be thought of as an indicator that a piece of code should be refactored – much like a foul smell in your refrigerator may indicate that it’s time to clean it out.
Again, as developers we all like to think that we are adhering to best practices when it comes to clean code, but it is important to reflect on your work and identify areas that can be improved upon. For instance, McFadyen points out some of these smells that almost appear to be directed at me:
- Data Clumps
- This smell refers to cases where method calls take the same set of parameters across different calls.
- This smell can indicate that these parameters are related and can be combined into a class to represent an idea or an object.
- Addressing this Code Smell can improve the organization of your code.
- “Primitive Obsession”
- Often it is easier and quicker to assign values to a primitive type in order to accomplish our goals. However, using primitives for these means is not always effective at communicating to others what that primitive is representative of.
- In these cases, it may be beneficial to create a basic class that better communicates that idea. McFadyen’s example is a string variable called “id” that needs to be validated. While we (and others) may have an idea that this is an identifier of some type, we don’t know what qualifies it as valid.
- In this example, we can wrap the “id” into a “ProductId” class with a validation method. This change can allow others to go read this class, understand that it is an identifier for a product, and understand what makes these identifiers valid.
- These changes can better communicate to other developers what the intent of the ID is.
It’s Important
By striving to improve the cleanliness of and working to eliminate the smells in our code, we not only improve ourselves but also enable those around us. Even though we all might think that we are doing our part to keep code clean and smell-free, it’s also important to take a moment to step back and reflect on what we can be doing better. Keeping your code clean and free of smells allows for increased effectiveness and efficiency of not only you, but your fellow developers.