Clean code is easy to read, easy to understand, and easy to maintain not only by the developers who developed it but also by others.
Aside from good SOLID principles and coding standards, code should tell a story that’s easy to comprehend. Similar to a joke, if you have to explain it…. Let’s take a look at an example.
Background information: We run an e-commerce site where customers search or browse our products. In order to entice customers to purchase products, discounts will be offered to certain customers and certain products will be discounted from time to time.
Business requirements:
Longer field names
Source level debugging
Date and time support
In summary, the requirements are, based on discounts, products, or customers, we want to offer the customer the lower of the two.
.net programming
Exhibit 1 – While this method does the trick, it is coupled to customer and product thus making it inflexible. In order to understand what this method does; one must sift through the code and code comments to understand that we’re calculating the lowest price based on two discount values. To use a story analogy, the title of the book, the method name, doesn’t portray the story being told.
.net development
Exhibit 2– This method name matches the story being depicted. While this method is not coupled to Customer and Product objects, the variable names and variable types make it a bit rigid. If for example, we wanted to calculate the lowest discount price for a vendor instead of a customer, the method would work, but the variable names wouldn’t make sense as we would be using customerDiscount to pass in a vendor discount. Going further down this rabbit hole, we might even write a similar method and change the variable name to vendorDiscount instead of customerDiscount thus having repeated code to be maintained.
.net programs
Exhibit 3 – This method performs the same functions as Exhibit 1 and 2 but without being coupled to customer, product, and their respective variable names. Its function is specific to performing one thing; calculate the lowest discount price based on several provided discounts. The price variable is not tied to product price; discounts are not tied to customers or products. It’s flexible in that it will accept a list of discounts as opposed to a limited number and calculates the lowest price based on those discounts.
Let’s push the envelope a bit; the product owner informs us of a new requirement. The product owner would like product discounts to also be date-driven; for example, 10% from January through November, 15% in the month of December. If a product’s discount schedule is not set up, then use the product discount. If both exist, then use the lower of the two discounts. Let’s look at one way to handle this change. This change requires us to introduce a new table and model class to store discount effective start and end dates. For the sake of this example, let’s call the table and model ProductDiscountSchedule. The caller of CalculateLowestDiscountPrice would need to pass in a list containing the customer and product discounts as before and now also add a discount for ProductDiscountSchedule for the effective start and end date falling between the current date.
Something like this:
.net programs
Because we wrote a flexible method which was not coupled, a clear and concise story, we were able to re-use it for a new purpose. While we can’t anticipate every change, we do know that change is inevitable. Writing clean code and following sound SOLID principles and coding standards allows us to more easily cope with change. Unclean code is difficult to read, hard to test, less flexible, and has a greater chance of being buggy. Writing clean code pays huge dividends in code maintainability, re-usability, and development costs irrespective of technology you use.
At a psychological level, writing clean code brings on a certain euphoria; clean code, clear mind; happiness.
Happy storytelling; keep it clean.
Top comments (0)