Coding Standards? I Think Mine Are Pretty High
24 Sep 2025ESLint more like ESWimp
To be honest, when I first heard the term “coding standards,” I assumed it mainly referred to small problems, such as whether to indent two spaces or four, or whether to use curly braces on the same line or the one after it. It sounded like the sort of demanding guidelines that were futile as long as the program functioned. However, after using ESLint in VSCode for a week, I began to see things differently. Coding standards cover consistency, dependability, and even improving language proficiency in addition to style. ESLint was distracting at first. Red and yellow underlines would show each time I wrote code. It would point out that my formatting wasn’t quite correct, that I had an unused variable, or that I used let when I should have used const. “The code works, so why does it matter?” was my first impulse. But as time passed on, those little underlines were learning opportunities. My thoughts were made simpler by using const rather than a let variable. My code was clearer and simpler to read after I eliminated unnecessary variables. With the addition of becoming more consistent with minor style guidelines like spacing and semicolons.
Thinking of standards in the context of collaboration of collaboration was something that I thought of. Although I currently work alone on the majority of my projects, I can already imagine how disorganized a team would be if each member wrote code independently. Thinking of reading code with half the variables written in a manner inconsistent with their intended use, one section using one case and another using camelCase, and indentation that fluctuates gives me chills down my spine. Attempting to understand the style would take up more time than actually resolving the issue. Standards clear up that confusion. They ensure that the code feels recognizable and predictable regardless of who wrote it.
I need to raise my standards
How the coding standards fit into the big picture of software engineering made sense to me as well. Coding standards govern how the code is written in the first place, and tools like Git and GitHub facilitate the management of code changes. They work hand in hand. Git manages the changes, and ESLint and coding standards ensure that the changes are readable and consistent. They jointly produce the impression that development is less random and more managed. ESLint is just like my coaches back at home. They might call me out on the small mistakes I’d rather ignore, but I know it’s because they want me to grow. At first, it can be frustrating to hear constant corrections, but over time I realize those details matter. The discipline they instilled in me carried over into how I play, and now ESLint is doing the same thing for how I code. It’s building consistency, accountability, and habits that will make me a stronger programmer.
All this to say that, yes, coding standards are a great way to raise the quality of my code. They make it easier—not just for me, but for anyone reading my work—to understand, maintain, and trust the code. ESLint has turned out to be much more valuable than I expected, and it’s helping me build habits that I hope I can carry forward. Even though it can be annoying to see those red and yellow lines, I think it’s worth it if it means holding myself and others to a higher standard for future projects.