{"id":21,"date":"2025-01-16T20:30:45","date_gmt":"2025-01-16T20:30:45","guid":{"rendered":"https:\/\/blogs.oregonstate.edu\/nicholasnelson\/?p=21"},"modified":"2025-01-16T20:30:45","modified_gmt":"2025-01-16T20:30:45","slug":"clean-code-vs-code-smells","status":"publish","type":"post","link":"https:\/\/blogs.oregonstate.edu\/nicholasnelson\/2025\/01\/16\/clean-code-vs-code-smells\/","title":{"rendered":"Clean Code vs. Code-Smells"},"content":{"rendered":"\n
Introduction<\/h2>\n\n\n\n
As an aspiring software engineer constantly learning new coding concepts and strategies, my coding practices have been improving both directly and subconsciously. Now that I am reaching the end of my journey as only a student of computer science, It’s important to recognize that mastering clean code principles and eliminating code smells are vital in building maintainable codebases . <\/p>\n\n\n\n
Clean Code<\/h2>\n\n\n\n
After reading an article from FreeCodeCamp.org on writing clean code, one thing I want to start doing more often is called the Single Responsibility Principle (SRP) which states that every class or module should only have one responsibility. <\/p>\n\n\n\n
Here are some examples found on FreeCodeCamp.org:<\/p>\n\n\n\n
\/\/ Example 1: Withouth SRP\nfunction processOrder(order) {\n \/\/ validate order\n if (order.items.length === 0) {\n console.log(\"Error: Order has no items\");\n return;\n }\n\n \/\/ calculate total\n let total = 0;\n order.items.forEach(item => {\n total += item.price * item.quantity;\n });\n\n \/\/ apply discounts\n if (order.customer === \"vip\") {\n total *= 0.9;\n }\n\n \/\/ save order\n const db = new Database();\n db.connect();\n db.saveOrder(order, total);\n}<\/code><\/pre>\n\n\n\n
The above code block shows processOrder which isn’t utilizing SRP. It handles several functions, which makes it hard to understand. Furthermore a change to one function may change the others which makes it hard to maintain. <\/p>\n\n\n\n
\/\/ Example 2: With SRP\nclass OrderProcessor {\n constructor(order) {\n this.order = order;\n }\n\n validate() {\n if (this.order.items.length === 0) {\n console.log(\"Error: Order has no items\");\n return false;\n }\n return true;\n }\n\n calculateTotal() {\n let total = 0;\n this.order.items.forEach(item => {\n total += item.price * item.quantity;\n });\n return total;\n }\n\n applyDiscounts(total) {\n if (this.order.customer === \"vip\") {\n total *= 0.9;\n }\n return total;\n }\n}\n\nclass OrderSaver {\n constructor(order, total) {\n this.order = order;\n this.total = total;\n }\n\n save() {\n const db = new Database();\n db.connect();\n db.saveOrder(this.order, this.total);\n }\n}\n\nconst order = new Order();\nconst processor = new OrderProcessor(order);\n\nif (processor.validate()) {\n const total = processor.calculateTotal();\n const totalWithDiscounts = processor.applyDiscounts(total);\n const saver = new OrderSaver(order, totalWithDiscounts);\n saver.save();\n}<\/code><\/pre>\n\n\n\n
This above code shows the same method but this time utilizing SRP. The processOrder has been split up into multiple classes, OrderProcessor and OrderSaver which gives each classes its own functionality. This makes the code easier to understand and maintain. <\/p>\n\n\n\n
Code-Smells<\/h2>\n\n\n\n
A code smell, which are indicators in code that reveal that there may be a problem in the design of the code, is something I am unashamed to admit that I am guilty of. The first step in correcting a problem is to admit you have one, and there is one thing that I wish to avoid doing in the future to make my code less smelly. <\/p>\n\n\n\n
Code duplication an easy issue to create, as it can be so easy to just ignore it because its functional, but failure to correct these kinds of problems early can make the codebase unmaintainable. By performing refactoring, one can remove duplicated code.<\/p>\n\n\n\n
Here are some examples of what I mean that I found on Medium.com:<\/p>\n\n\n\n
\n<\/figure>\n\n\n\n
<\/p>\n<\/div>\n\n\n\n
The above code block shows two functions can contain duplicate code, one function to calculate the area of a rectangle, and the other to calculate the perimeter. While they do serve to distinct purposes, the code is so incredibly similar they don’t need to be in two different functions. <\/p>\n\n\n\n<\/figure>\n\n\n\n
The code block above shows the refactored version, which creates a function that utilizes the logic of the area function, and simply reuses it for the perimeter. This solves the issue with duplicate logic and improves maintainability. <\/p>\n\n\n\n
![\"\"](\"https:\/\/osu-wams-blogs-uploads.s3.amazonaws.com\/blogs.dir\/8109\/files\/2025\/01\/Screenshot-2025-01-16-120208-1-1024x273.png\")
<\/figure>\n\n\n\n![\"\"](\"https:\/\/osu-wams-blogs-uploads.s3.amazonaws.com\/blogs.dir\/8109\/files\/2025\/01\/Screenshot-2025-01-16-120120-1024x414.png\")
<\/figure>\n\n\n\n