I remember the first time I wrote a Microsoft Word essay back in middle school, the page was literally littered with red and green squiggly lines reminding me (taunting me, rather) of my spelling and grammar mistakes. As irritating as that was, I can’t complain about it now. Perhaps it was that very process of writing, making mistakes, and correcting those massively annoying squiggly lines that facilitated my proficiency in the english language (I mean that with the slightest tinge of sarcasm).
Now here I am years later and I find myself pretty much in the same scenario as my middle school self: writing, making mistakes, and correcting unsightly red squiggly lines. You see, I’ve recently started using the ‘IntelliJ’ IDE (Integrated Development Environment) with an ESLint extension that scans my code and tells me when my code does not meet the prescribed standard, a.k.a mistakes. In my first week of using IntelliJ with ESLint, trust me, the mistakes were frequent and aggravating.
Unlike Microsoft Word however, IntelliJ will still run your code even if you have a few formatting errors. You could write a program using logically consistent JavaScript and IntelliJ will still compile your code. But, when you enable ESLint and you add in some extra spaces, forget to put a space between your function name and parameter, or even write 121 characters in a given line of code (max is 120, found that out the hard way), IntelliJ will not hesitate to let you know with a red squiggly line. (Results vary depending on what packages you install for your project). But, if IntelliJ will still run your code despite some formatting errors, what’s the point of having coding standards? Your code will still run, so what’s the benefit?
Well, let me put it this way. If you bought a recipe book and the author decided to write with inconsistent metrics, jarring indentations, and inconsistent spacing between words, wouldn’t you as the reader get flustered, frustrated, and flabbergasted? You wouldn’t know the difference between teaspoon and tablespoon or sugar from salt. You’d probably throw that book in the trash! This same notion of reader friendly documentation extends to IntelliJ and ESLint. Majority of software engineers do not work in isolation but work interdependently with many different other engineers. Imagine if every engineer working on a project had their own idea and their own version of subjective coding standards: they became their own recipe book author in a sense. Coding standards matter because they help us, as developers, work together seamlessly and efficiently.
That being said, adapting to coding standards has been met with resistance this past week. As frustrating as it was to correct my code to comply with my instructors prescribed coding standard, I did find some joy. I found some comfort in knowing that the practices that I was adapting to and the rules I was learning would someday help me when I work with other engineers. So I guess what I’m saying is that, yes red squiggly lines are annoying, but I’ll adapt and hope that it’ll help me in the long run.
Touché, IntelliJ. You win this round.