Coding standards are often reduced to minor stylistic preferences, with people debating over the use of two spaces or four, tabs or spaces, single quotes or double quotes. At first, I shared the same belief because it seemed excessive to treat formatting choices as a serious concern. However, after my first week using ESLint in Visual Studio Code, I started to view it differently.
Initially, the experience was frustrating as red underlines appeared throughout my code. ESLint objected to my indentation, my quotation marks, and even small habits I had developed over time. I remember thinking: why does it matter if I use the Tab key instead of two spaces? Why insist on single quotes when double quotes seem clearer? The amount of errors made it feel as though I was fighting the tool rather than writing software.
As I worked through the warnings, I realized that many of them were not merely stylistic. ESLint highlighted unused variables, inconsistent return statements, and unsafe equality comparisons. In correcting these issues, I was not just complying with a formatting rule; I was learning more about the coding language and avoiding subtle mistakes. The tool functioned as a quiet mentor, pointing out patterns that experienced developers have learned to avoid.
Over time, the irritation diminished. Once automatic formatting was enabled, the smaller stylistic decisions disappeared from my workflow. The standards were no longer obstacles; they became background structure. With consistency enforced automatically, I could focus more on problem-solving and less on presentation.
Coding standards, when thoughtfully applied and automatically enforced, are not about aesthetics. They reduce cognitive load, encourage best practices, and make collaboration smoother. My first week with ESLint was both uncomfortable and instructive, but ultimately, it demonstrated that even small constraints can meaningfully improve the clarity and quality of code.