Having been at Arcurve now for six months, I am admittedly still trying to figure out what exactly quality code is. Back when I was in school, the metrics for the code we wrote were straightforward – there was usually only one: does the code work?

Thankfully, in real life industry, there is more to it than that.

I’m not going to try and define quality code in this blog post, as I am still trying to figure that out, and I will probably go my entire career without having a true definition of what it actually is..  What I will discuss are four things I’ve learned to keep in mind when trying to write quality code.

1. Keep it simple. When I first started working at Arcurve, I often wrote entire functions, that after a review from the other devs, could be condensed down into a single line. While at the time it only seemed like an alternative method for accomplishing the same job, I realize now, there are many benefits to writing simple code other than just looking good. Simple code is much less prone to bugs, and also ties into expandability and maintainability. Simplistic code is easy to understand and is arranged to extend the existing functionality of an application. Simplistic code is also more resistant to tech debt with time.

2. Consistency is king. Keeping Code in line with what is already there allows other devs to understand your code easily and quickly. If other devs can understand it, then they can also work on it. Not only is this a benefit for other devs, but it is also an awesome bonus for you. As devs, the hardest part of our job is creating solutions. But often the solution has already been solved somewhere else, which just leaves us the job of changing the context.

3. Readability matters. Coming from school, most of my variable names were things like “x” or “ptr”. But looking back at my old projects/assignments, even though I coded them myself, I can’t make any sense of it. Having been in the industry, descriptive variable names have been an immense help to understanding the code base. Not only that, but seeing well structured, clear code, have also been super helpful in figuring out how the code base functions. You won’t see any recursion in our code!

4. Can you test it? Creating code that is easy to test is not just beneficial for the person that writes the test, but for other devs as well. Creating functions with a finite amount of responsibility makes testing simple and creates an easy to understand code base. Not only that, but if the unit tests are clear in what they are testing, they are a wonderful form of documentation for the code base.

Overall, in my experience working at Arcurve so far, I’ve learned that code is not written just for yourself, but for others. Even though I am an intern, it is likely that after my internship ends, other developers of all levels of experience will see my code long after I’m gone. Even crazier, is that my code could influence how new components are designed. So, it is necessary to consider things like code readability and expandability to help other developers navigate and potentially build off the code you wrote.

If you are interested in learning about writing quality code, I highly recommend checking out “Clean Code” by Robert C. Martin for more.