Clean code is code that’s easy to read, easy to understand, and easy to maintain by other developers be it .net technology or any other. 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.
- 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.
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.
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 customer discount 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 vendor discounts instead of customer discount thus having repeated code to be maintained.
Exhibit 3 – This method performs the same functions as Exhibit 1 and 2 but without being coupled to the 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 Product Discount Schedule. The caller of Calculate Lowest Discount Price would need to pass in a list containing the customer and product discounts as before and now also add a discount for Product Discount Schedule for the effective start and end date falling between the current date.
Something like this:
Because we wrote a flexible method that 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, reusability, and development costs irrespective of the technology you use.
At a psychological level, writing clean code brings on a certain euphoria; clean code, clear mind; happiness.