{"id":16,"date":"2025-01-14T20:29:32","date_gmt":"2025-01-14T20:29:32","guid":{"rendered":"https:\/\/blogs.oregonstate.edu\/flowe\/?p=16"},"modified":"2025-01-14T20:47:18","modified_gmt":"2025-01-14T20:47:18","slug":"getting-rid-of-stinky-code","status":"publish","type":"post","link":"https:\/\/blogs.oregonstate.edu\/flowe\/2025\/01\/14\/getting-rid-of-stinky-code\/","title":{"rendered":"Getting Rid of Stinky Code"},"content":{"rendered":"\n

If you are a programmer, and have been for even a year, chances are you have seen what you might consider to be messy code; I for sure have. It’s the code that looks like someone’s mind threw up what they were trying to do, but yet it doesn’t quite do it; or if it does, the methods it uses are so ridiculous you just close the page because you can’t stand the sight of it. Luckily, from early on in my learning, I worked in a group with someone who embodies clean code. What he wrote was beautiful. I learned so much from him and, over the last year, have tried to adapt it to my own development workflow.<\/p>\n\n\n\n

What to Begin<\/h2>\n\n\n\n

With that being said, one major takeaway from what I\u2019ve learned from him and from the article about clean code is that writing clean code starts at the very beginning of developing any piece of software [1]. Bjarne Stroustrup put it best: \u201cClean code does one thing well.\u201d [1]. While a piece of software must accomplish multiple tasks, each component of that software, such as a function, should do one thing\u2014and do it exceptionally well. For example, in web development, a React component should focus on a single responsibility. If it\u2019s handling form input, it shouldn\u2019t also concern itself with data fetching or state management.<\/p>\n\n\n\n

Here is an example of a React component that could be considered “Messy Code”:<\/p>\n\n\n\n

RecipeSearch.js<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

Here is an example of the “Messy Code” above becoming “Clean Code”:<\/p>\n\n\n\n

SearchForm.js<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

SearchResults.js<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

RecipeSearch.js<\/strong><\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

In the “Messy Code” example, the RecipeSearch<\/code> React component is doing multiple things at once. It handles state management, user input, API fetching, and rendering the results\u2014all within a single component. While it might perform what it needs to do, reading and understanding it can be challenging, and maintaining or extending it could lead to errors in the future.<\/p>\n\n\n\n

The “Clean Code” example separates all the functions of the RecipeSearch<\/code> into three distinct components, each with a single responsibility:<\/p>\n\n\n\n

    \n
  • SearchForm<\/code><\/strong>: Responsible solely for rendering the search form and handling user input. This makes it easy to understand and reuse if the same form structure is needed elsewhere in the app.<\/li>\n\n\n\n
  • SearchResults<\/code><\/strong>: Handles the display of search results, ensuring the rendering logic for the results is isolated from the state management and data fetching.<\/li>\n\n\n\n
  • RecipeSearch<\/code><\/strong>: Manages the overall state, orchestrates the API calls, and connects the SearchForm<\/code> and SearchResults<\/code> components. It serves as a higher-level controller, keeping the logic centralized but the presentation decoupled.<\/li>\n<\/ul>\n\n\n\n

    By following this approach, the code becomes easier to read, test, and maintain. Each component is focused, making it less likely that changes in one area will accidentally introduce bugs elsewhere. This is something I already do, but need to do from the beginning of writing code, instead of just going back through the “messy” code and refactoring it to become “clean” code.<\/p>\n\n\n\n

    What to Avoid<\/h2>\n\n\n\n

    On the other hand, from the article about bad code smells, one habit I need to work on avoiding is the Long Method. Long methods are difficult to understand, maintain, and extend. They kind of just happen if you’re not careful. They often try to do too much at once, leading to clutter and confusion [2]. The idea is simple: shorter methods are easier to read and manage because they focus on a single task. Modern object-oriented languages such as TypeScript eliminate much of the overhead of subroutine calls, making it practical to use many small methods instead of one long one.<\/p>\n\n\n\n

    This thing to avoid ties in very well to the concept of clean code. Long methods often indicate that a function is trying to handle multiple responsibilities, which goes against the principle of \u201cdoing one thing well.\u201d Breaking down a long method into smaller, more focused methods not only makes the code easier to read but also improves reusability and testing.<\/p>\n\n\n\n

    For example, let\u2019s revisit the handleSearch<\/code> function from the messy RecipeSearch<\/code> component. In its current form, it does everything: preventing the default form submission behavior, updating the loading state, fetching data from the API, and handling both success and error states. This approach makes the method long and harder to maintain.<\/p>\n\n\n\n

    Instead, by applying the principle of breaking down long methods, we could refactor it into smaller, more focused functions:<\/p>\n\n\n\n

    \"\"<\/figure>\n\n\n\n

    Here, handleSearch<\/code> delegates specific tasks to smaller, dedicated functions like fetchRecipes<\/code>, updateResults<\/code>, and logError<\/code>. Each function has a single responsibility, making the code easier to follow and less error-prone.<\/p>\n\n\n\n

    Final Thoughts<\/h2>\n\n\n\n

    The road to writing clean, maintainable code starts with awareness and deliberate practice. By focusing on principles like separation of concerns, avoiding long methods, and prioritizing readability, we can significantly improve the quality of our codebases. While refactoring messy code into clean code is an essential skill, the ultimate goal should be to write clean code from the very beginning. This not only saves time and effort but also creates a foundation for scalable and robust applications.<\/p>\n\n\n\n

    As developers, it\u2019s our responsibility to strive for clarity and simplicity in our work. After all, clean code doesn\u2019t just make our lives easier\u2014it makes our codebases a joy to work with for everyone.<\/p>\n\n\n\n

    Sources<\/h2>\n\n\n\n

    [1] R. C. Martin, Clean code a handbook of agile software craftmanship.<\/em> Upper Saddle River [Etc.] Prentice Hall, 2010.<\/p>\n\n\n\n

    [2] M. Fowler, Refactoring: Improving the design of existing code<\/em>. Boston: Addison-Wesley, 2019.<\/p>\n\n\n\n

    \u200c<\/p>\n\n\n\n

    \u200c<\/p>\n","protected":false},"excerpt":{"rendered":"

    If you are a programmer, and have been for even a year, chances are you have seen what you might consider to be messy code; I for sure have. It’s the code that looks like someone’s mind threw up what they were trying to do, but yet it doesn’t quite do it; or if it […]<\/p>\n","protected":false},"author":14559,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[12],"tags":[],"class_list":["post-16","post","type-post","status-publish","format-standard","hentry","category-coding-topics"],"_links":{"self":[{"href":"https:\/\/blogs.oregonstate.edu\/flowe\/wp-json\/wp\/v2\/posts\/16","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/blogs.oregonstate.edu\/flowe\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.oregonstate.edu\/flowe\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/flowe\/wp-json\/wp\/v2\/users\/14559"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/flowe\/wp-json\/wp\/v2\/comments?post=16"}],"version-history":[{"count":6,"href":"https:\/\/blogs.oregonstate.edu\/flowe\/wp-json\/wp\/v2\/posts\/16\/revisions"}],"predecessor-version":[{"id":32,"href":"https:\/\/blogs.oregonstate.edu\/flowe\/wp-json\/wp\/v2\/posts\/16\/revisions\/32"}],"wp:attachment":[{"href":"https:\/\/blogs.oregonstate.edu\/flowe\/wp-json\/wp\/v2\/media?parent=16"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/flowe\/wp-json\/wp\/v2\/categories?post=16"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.oregonstate.edu\/flowe\/wp-json\/wp\/v2\/tags?post=16"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}