It's not all about the functionality

26 Sep 2019

Style matters!

As programmers, our immediate objective is always to get our code working. Whether your first introduction to programming was in high school or in college (or you are self-taught!), you likely have faced multiple situations where you placed priority on the functionality of your program over best practices. Yet, this can have long-lasting consequences on not only you as a programmer, but also others who may have to read your code in the future.


Why are coding standards so important?

Most introductory courses in Computer Science do not place emphasis on standards and coding style, from my experience as a Computer Science student. Usually, these courses are more concerned with your programming skill and solving the task at hand, rather than scalability. When you are hired in the future for a Software Engineer position or equivalent, however, this is not sufficient for the company’s success. One of my previous professors placed significant emphasis on the structure of our code, and though it felt like he was a harsh grader at the time, it all makes sense now. He would tell us that one small bug that could arise due to poor coding structure could mean thousands of dollars going down the drain every second for the company.

Many students in this course have faced this problem, except that rather than losing money, we spent countless hours staring at our computer screens with no real solution to our problem. Yes, placing curly brackets on their own line can make a huge difference. These small things are easily overlooked by many programmers, since it does not usually affect the way their program runs. Yet, the true pain of spaghetti code will become apparent when their time comes to evaluate a team member’s code for a project or to replace someone at a new workplace.

ESLint to the rescue

This is where ESLint comes to the rescue!

… well, at least to some extent. The Software Engineering course at UH Manoa utilizes ESLint to enforce coding standards for assigments. This is very similar to Checkstyle, which was also another “developmental tool” used by the Intro to Computer Science II course at UH Manoa. These tools can significantly assist students with catching typos or syntax errors that may otherwise go unnoticed due to various reasons. Besides, who wants to stare at their own code for an hour? These tools can save minutes, or even hours that would usually be spent scanning a program line by line for errors!

There are some instances where tools like ESLint have actually helped me learn some new programming concepts. Usually these are subtle things like spacing or indentation but nonetheless they can be very helpful to you as a programmer. For instance, ESLint may warn you that you have not used curly braces in the following code for the if and else statements:

function testFunction() {
    if (errorProne)
        return true;
    else 
        return false;
}

While at first glance, this seems like nothing more than a personal style preference, it could become the source of a huge problem if the code will be edited in the future. A perfect real-world example is an Apple SSL/TLS bug that occured a while ago. The source of the serious “signature verification” problem was caused by just that one careless mistake. That COULD put a programmer’s career on the line. So yes, ESLint can be a lifesaver!

Prevent future disasters!

Though this is not the first time I am using a tool to check my adherance to code standards, it has definitely reinforced the importance of following them, especially when it comes to working in a team. No one wants to encounter the nightmare of tracing through code that is indecipherable. Dr. Johnson believes that “some coding standards can actually help you learn a programming language”, and I absolutely agree. Using these tools have helped me write scalable code as well as learn some new features of languages through the exposure of new errors. Rather than seeing errors as a failure of accomplishing the end goal, they should be considered an oppurtunity to learn. The more experience, the better!


Source for the Apple SSL/TLS bug (thank you Stack Overflow!) : https://stackoverflow.com/questions/2125066/is-it-a-bad-practice-to-use-an-if-statement-without-curly-braces