{"id":63,"date":"2025-01-14T22:51:19","date_gmt":"2025-01-14T22:51:19","guid":{"rendered":"https:\/\/blogs.oregonstate.edu\/hridayblog\/?p=63"},"modified":"2025-01-14T23:41:16","modified_gmt":"2025-01-14T23:41:16","slug":"clean-code-and-code-smells","status":"publish","type":"post","link":"https:\/\/blogs.oregonstate.edu\/hridayblog\/2025\/01\/14\/clean-code-and-code-smells\/","title":{"rendered":"Clean Code and Code Smells"},"content":{"rendered":"\n

Introduction<\/h3>\n\n\n\n

Writing clean code is not just a skill; it\u2019s a responsibility every programmer should embrace. Clean code makes a codebase easier to read, maintain, and debug, which saves time and prevents headaches. On the other hand, code smells are warning signs that indicate deeper issues in the code, leading to technical debt and maintenance nightmares. After reading \u201cWhat Is Clean Code?\u201d<\/strong> by Codacy and \u201cCommon Code Smells\u201d<\/strong> by 8th Light, I\u2019ve identified one practice I want to adopt more often and one practice I want to avoid at all costs.<\/p>\n\n\n\n

What I Want to Start Doing: Writing Short, Single-Purpose Functions<\/h3>\n\n\n\n

One of the principles of clean code that stood out to me was writing short functions that do only one thing<\/strong>, also known as the Single Responsibility Principle (SRP)<\/strong>. Breaking down a function into smaller, purpose-driven chunks makes code more readable, easier to debug, and reusable in different parts of a project.<\/p>\n\n\n\n

Here\u2019s an example of bad practice, where a single function is overloaded with multiple responsibilities:<\/p>\n\n\n\n

\n def process_order(order):\n     # Validate order\n     if not order.is_valid():\n         return \"Invalid order\"\n     # Calculate total price\n     total_price = sum(item.price for item in order.items)\n     if order.has_discount:\n         total_price *= 0.9  # Apply discount\n     # Save to database\n     database.save_order(order, total_price)\n     return \"Order processed\"\n\n<\/code><\/pre>\n\n\n\n
This function is doing too much: validation, calculation, and saving data. It\u2019s a classic code smell, known as Long Methods, as described in the 8th Light article.<\/p>\n\n\n\n
Here\u2019s a cleaner, refactored version:<\/p>\n\n\n\n
\n def validate_order(order):\n     if not order.is_valid():\n         return False\n     return True\n\n def calculate_total_price(order):\n     total = sum(item.price for item in order.items)\n     if order.has_discount:\n         total *= 0.9\n     return total\n\n def save_order(order, total_price):\n     database.save_order(order, total_price)\n \n def process_order(order):\n     if not validate_order(order):\n         return \"Invalid order\"\n     total_price = calculate_total_price(order)\n     save_order(order, total_price)\n     return \"Order processed\"\n\n<\/code><\/pre>\n\n\n\n
Each function now has a single purpose, making it easier to read, debug, and test independently. I aim to implement this principle consistently in my future projects.<\/p>\n\n\n\n
What I Want to Avoid: Hard-Coded Values<\/h3>\n\n\n\n
From the Codacy article, I learned about the problems caused by hard-coded values<\/strong> (magic numbers). They reduce readability, make code harder to maintain, and increase the risk of errors when requirements change. For example, imagine encountering this piece of code in a large codebase:<\/p>\n\n\n\n
\n if user.age > 18:\n     discount = order_total * 0.1  # 10% discount\n else:\n     discount = 0\n\n<\/code><\/pre>\n\n\n\n
While the logic works, it\u2019s unclear why the age is set to 18 or why the discount is 10%. This ambiguity can confuse other developers (or even future me).<\/p>\n\n\n\n
A better approach is to use named constants:<\/p>\n\n\n\n
 \n MINIMUM_AGE_FOR_DISCOUNT = 18\n DISCOUNT_RATE = 0.1\n \n if user.age > MINIMUM_AGE_FOR_DISCOUNT:\n     discount = order_total * DISCOUNT_RATE\n else:\n     discount = 0\n\n<\/code><\/pre>\n\n\n\n
Now, the code is self-documenting, and any changes (e.g., raising the age threshold to 21) can be made in one place.<\/p>\n\n\n\n
The Importance of Clean Code<\/h3>\n\n\n\n
Clean code isn\u2019t just about aesthetics; it\u2019s about functionality and teamwork. Clean code ensures that:<\/p>\n\n\n\n
    \n
  1. New team members can onboard quickly.<\/strong> They don\u2019t need hours to decipher poorly written code.<\/li>\n\n\n\n
  2. Debugging becomes easier.<\/strong> Clear code makes it simpler to pinpoint the source of issues.<\/li>\n\n\n\n
  3. Future changes are painless.<\/strong> Maintainability is a critical aspect of software longevity.<\/li>\n<\/ol>\n\n\n\n
    Recognizing and Addressing Code Smells<\/h3>\n\n\n\n
    Code smells are subtle signs of trouble in the codebase. While they don\u2019t always break functionality, they make code harder to maintain and extend. Some common smells I\u2019ll actively look out for include:<\/p>\n\n\n\n