I read Chapter 1 of Robert Martin’s book Clean Code: A Handbook of Agile Software Craftsmanship to gain a better understanding of what clean code truly means. One habit I want to work on is avoiding the rush and ensuring that my code remains clean throughout the entire development process. In the book, Martin highlights a common mindset among developers:
“Were you trying to go fast? Were you in a rush? Probably so. Perhaps you felt that you didn’t have time to do a good job; that your boss would be angry with you if you took the time to clean up your code. Perhaps you were just tired of working on this program and wanted it to be over. Or maybe you looked at the backlog of other stuff that you had promised to get done and realized that you needed to slam this module together so you could move on to the next. We’ve all done it.” (Martin, 3).
As a student, I’ve fallen into all of these traps, often resulting in poorly written code. While the code technically worked, it was rushed and lacked quality. Moving forward, I want to ensure that I take my time and focus on writing clean code throughout the entire process.
Martin also quotes Michael Feathers, who says, “I could list all of the qualities that I notice in clean code, but there is one overarching quality that leads to all of them. Clean code always looks like it was written by someone who cares.” (Martin, 10). This resonates with me—I want my code to reflect that I care, not that I was simply trying to finish as quickly as possible.
Writing clean code as a student can be challenging due to strict deadlines and the constant pressure of juggling multiple projects. However, after reading Clean Code, I recognize how crucial it is to build this habit now, before entering the workforce. In my upcoming assignments, I plan to prioritize clean code and ensure it becomes a standard part of my workflow.
I read Chapter 8 of Oregon State University’s Handbook of Software Engineering Methods: Code Smells and Refactoring to better understand what constitutes bad code. Code smells are signs that the code needs refactoring, and this chapter focuses on common issues in comments, functions, and duplicate code.
One issue I want to avoid is writing long functions or functions with too many parameters. The handbook offers practical advice for these situations:
“Long Function (more than 10 lines or so). Break into multiple functions. Aim for five lines or fewer. Function with Many Parameters (more than four, some say more than three). As appropriate, pass an object that combines the parameters, make calls within the function to get the parameter data, break into multiple functions, or find another way of reducing the number of parameters.”
This guidance makes it easier to recognize when a function might have a code smell. Having clear limits, like a maximum of 10 lines or 4 parameters, provides a helpful benchmark. To ensure my code stays clean, I will make sure my functions are focused and only do one thing. As stated in Clean Code, Bjarne Stroustrup emphasizes that “Clean code does one thing well.” (Martin, 7).
~ Madison Dowell