When I first used ESLint in VSCode, I received a flood of error messages. It was frustrating, especially because I wasn’t always sure how to fix them. At first, it reminded me of TypeScript, but even more strict. Most of my errors were spacing and naming conventions, and at the time, it felt like extra work on top of stressful, timed assignments. Over time, however, I came to see that coding standards serve the same purpose as static typing: catching issues early, improving readability, and making debugging easier.
My first impression of ESLint was annoyance. Small issues like missing spaces, variable naming mistakes, or extra blank lines seemed trivial compared to just getting my program to run. But the more I worked on assignments and WODs, the more I realized those “small” issues often pointed to bigger problems. In a practice WOD, for example, I had a typo in a function name. Without ESLint, I might have wasted much more time tracking it down. Instead, the linter flagged the issue and forced me to slow down, review my code carefully, and fix it before it caused other bugs. What initially felt like extra work turned out to be a way of adding discipline to my coding habits.
At first glance, coding standards seem to slow things down. They add more work upfront, much like TypeScript. But that extra work pays off later. Clean and consistent code isn’t just for you—it benefits your teammates and future collaborators. Employers and peers will value readable, maintainable code as much as functional code. On a team project, consistent naming conventions, structure, and layout can save hours of debugging and frustration. Ultimately, it’s not the compiler that cares about standards—it’s your team.
I don’t think newcomers should be expected to learn coding standards immediately. Learning the basics of programming is already challenging, and enforcing strict formatting rules too early can be overwhelming. Instead, I believe coding standards are most useful after a programmer has some background. Once you understand variables, functions, and loops, you can start adding standards to make your code stronger and more professional. This balance helps beginners avoid frustration while still preparing them for the expectations of real-world software development.
What once frustrated me became a valuable learning experience. ESLint has shown me that the little things matter—not just to satisfy a linter, but because those details bring clarity, and clarity leads to better, more maintainable code. Coding standards may not be exciting, but they’re a habit worth building. Just as static typing prevents subtle bugs, coding standards prevent messy codebases. With practice, I’ve come to see ESLint not as a burden but as a tool that will make me a stronger programmer in school, internships, and eventually, in professional software engineering roles.
Used ChatGPT for formatting and grammar