This week I decided I wanted to read a blog post as opposed to a podcast for my blog entry. I went to the slack channel and found an article posted by Jason Knowles on writing clean code. Before reading the article, I knew had a general idea of what clean code was supposed to be, but lacked depth in understanding. Clean code is tremendously important in becoming a strong software engineer. Without a good understanding of writing clean code, a developer will never be successful in effectively contributing to a team. My goal and reasoning for choosing this blog post was to get a better idea of what clean code is exactly and how to work towards consistently writing it.
The blog post opens up a general overview of what clean code is and it’s importance in software maintenance. This flows into the main portion of the post, which is the practices to follow to ensure that one’s code is clean. The post ends with a few sections about code review, pair programming, and other resources.
One of the areas in the post that stuck with me the most is the topic of methods/functions performing a single operation. If a method performs multiple operations, it is probably a good idea to split this method into two different calls. This concept relates to the idea further discussed in the post about inline code VS function calls. The writer identifies that there isn’t one perfect solution for every given problem. In some scenarios, inline code is a better solution than creating a function/method to solve an operation. What comes to mind immediately to me is situations where a few operations will clearly never be needed elsewhere in the application and writing a longer method/function once will make future maintenance and understanding easier. The scenarios where method calls are better seems to be the vast majority of the time.
Another area in the post that caught my attention is the area regarding comments. The writer discusses the idea that comments are often a sign of poor code. This caught me off guard as I’ve always used comments as a way to remember what a function does for future additions and changes to my applications. The author writes that “comments should explain where code cannot” and that comments should be used to explain unconventionally written code. From reading the rest of article, it seems that if the code is written unconventionally, the comments are still a cover-up for poorly written code. This may be a poor code base that the current developer is simply writing an addition to, but does not have time to fix a poor code base.
In my first couple of years as a CS major, I have struggled with writing clean code and I feel that this article will help me in the future to write, scalable, easy to maintain code.
For anyone interested, here is the article this post is about.