Many programmers can’t grasp the importance of following coding standards; they think that as long as their code compiles and runs properly, there’s no harm in having strange indents and spacings in their code. This may be an acceptable view to have for small individual projects, but not following some sort of coding standard in real world applications of software engineering can cause many problems. I believe that being able to follow coding standards is an important quality to have in order to be a successful software engineer.
It’s clear that coding standards improve the readability of code. When a file is more readable, people don’t have to waste as much time deciphering the intentions of the code. Having neat code is especially useful in team projects since it saves the time it takes to understand a team member’s code and makes collaboration easier. You can’t assume that everyone else will be able to understand your code as well as you can if they are not familiar with your way of programming. I definitely appreciate neat code when I’m trying to modify someone else’s code or build off of it.
Among the general benefits of having your code abide by coding standards, you can also more easily learn new programming languages by studying and writing code that is correctly structured. Following coding standards can help you learn languages faster by making it easier to read and therefore study. Through the use of proper indentation, it also helps you see what code is nested inside of which loop, function, etc.. In general, neat code helps with understanding the structure and intent of a file or a function.
One way to ensure that your code obeys a certain coding standard is by using a linter tool such as ESLint that checks your code and flags instances that don’t follow the given rules of formatting. In addition, ESLint helps catch many simple and common errors, such as a forgotten semicolon. Coding with ESLint reminds you to follow coding standards and helps you form the habit of writing readable and well-organized code. However, ESLint is sometimes annoying because of some picky standards that I’m not used to following such as putting a space between ‘for’ and the following parenthesis when typing out a for loop. Once I become more familiar with the proper formatting and the common types of errors ESLint catches, I should start getting less errors. In the meantime, the tool is helping me train to be a better software engineer.