Introduction
As an engineer, I am very particular about the way my space looks. I keep my bedroom neat and tidy with no misused space. However, as an artist, I also do not leave any space on my wall uncovered by a picture, shelf, or tapestry (as long as it isn’t cluttered of course). Because I work and take classes from home, it is often hard to separate my work and home life. But the one principle I take into both, is neatness and organization.
Keeping my code clean is a way of keeping my computer screen organized. I like to operate in an extremely controlled environment and when my workspace gets jumbled, it makes it difficult for me to work. I see my computer as another decoration in my room and I like it to look just as neat as everything else. Which is why I emphasize my code’s cleanliness in school, work, and even my own personal projects.
What makes code clean?
There is no one “right” way to write clean code. If every musician had the same vision for the perfect piece, there would be no diversity in your playlists. That is why it is important to note that there is an art to coding and everyone has their own personal style. Not everyone will follow the exact same formatting rules because not everyone visualizes the code on the screen in the same way. However, there are many important standards and practices that should be followed in order for your code to be legible to others.
I will be going through a few key topics that are highlighted in this article written by German Cocca: https://www.freecodecamp.org/news/how-to-write-clean-code/. The article discusses a wide variety of clean code principles but a few of my favorites that I would like to focus on in my code-writing career have to do with efficiency and consistency.
Efficiency
When it comes to coding, efficiency and legibility go hand in hand. If you write long, convoluted code, it will be extremely difficult to go back and debug, regardless of it works or not. The image below is an example of inefficient code.
Obviously, this code was written as a joke. But it can be used as a good exercise for writing clean code as we find a solution with only one line in the body of the function. Although basic, the below function is a great demonstration of how we can rewrite code to be clean and efficient.
private bool IsEven(int number){
return (number % 2 == 0);
}Consistency
Consistency is one of my favorite parts of my coding. It creates aesthetically pleasing code that is easy to follow. A piece of code with proper and consistent formatting is like a work of art to me. I always love looking back over my code and seeing everything fall into place like a big puzzle.
The great thing about consistency is that it doesn’t require you to be consistent in any specific way. You are able to personalize your formatting for functions and variables as long as you are consistent. One of my favorite examples of this is case conventions. There are a variety of different case conventions such as camelCase, PascalCase, and snake_case (demonstrated within the name). All of these are completely valid but it is up to the coder to decide what they like best. My personal favorite case conventions are snake_case for function declarations and camelCase for variables.
Code Smells
Apart from writing clean code, it is also important to watch out for things called “code smells”. This article written by Georgina McFadyen describes a few examples of these: https://8thlight.com/insights/common-code-smells. One example that caught my eye (because I do this) was data clumps. Data clumps happen when related variables are often called together repeatedly. One example I found from my own project was:
func add_coll_object(objPosition, function, scene, object):All of the parameters of this function are aspects of every coll_object but they are all passed through my code separately which often gets very confusing. After reading through this article on code smells, I see that this is a much inferior method of handling these variables. I actually took a break from this project because the way that I wrote it initially became too much of a headache to figure out but now I have the tools to fix it. I am very glad that the research for this blog post could shine a light on the real problem in my project.