
Although I was aware of common coding standards in the past, I never realized the extent to which they could reach. Having to make sure your code is formatted in such a strict way, such that no errors appear in ESLint feels like a waste of time. However, it goes without saying that these coding standards are extremely useful in certain scenarios, especially when multiple people are collaborating on a project. Incorporating these new, stricter coding standards turns a program from “I need to be able to understand my code” to “I need others to understand my code”.
Without coding standards, people tend to code in whatever style feels comfortable to them. For example, I usually do not put spaces in certain areas where others might because it looks better to me, and helps me read my own code better. With these stricter coding standards, there is little to no agency in coding style. While you may no longer be able to tell who wrote the code, this is considered to be a good thing, as having a consistent style among multiple people will greatly increase everyone’s ability to read the code. It’s like having multiple dialects across one language: If everyone learned and used the common dialect, communication would become much easier. While it may be annoying and tedious to adhere to these stricter coding standards at first, it will ultimately benefit all collaborators in the long run.
Although in most cases it would be beneficial to adhere to these coding standards, sometimes you may be able to ignore them. For example, if I was working on a project alone, in which I just needed my program to fulfill a small purpose such as automating a simple task, I may not need these coding standards. As long as I write code that is easily decipherable to me personally, there isn’t much reason to be hunting the red squigglies that appear with ESLint. Ultimately, the functionality of the code should be the priority in simple tasks, and spending a lot more time to improve readability on code that you will never see again is pointless.