Rules for Rules Sake
10 Feb 2026
Because I said so
For those with a military background, standards are everything - Standards dicatate specific and measureable rules that could range from what temperature you are allowed to wear certain articles of clothing, to how many inches above a coat pocket you wear your ribbons, and even how to conduct yourself on and off the military installation. This ensures that every individual in the organization looks and acts “the same”, or a cohesive unit. When it comes to coding standards in software engineering, many people see it as those annoying rules and stipulations that “don’t really matter”, i.e., how many spaces you have to indent, where to place the curly bracket, and similar items. Many times, its presented as a preference, largely due to how advanced many software engineering languages have become in correctly assuming what you meant by certain lines, and fills in those gaps for you.
However, I’ve always adopted the idea that rules are the result of an action that ultimately negatively affected a person. Have you ever seen one of those caution labels that made you feel smart just by reading them? Like the stroller that has a sticker that says “Caution: Remove child before folding”, or a bag of fishing hooks that says “Warning: dangerous if swallowed”. While these seem obvious, these situations have likely occured, causing the company or creator to make those stipulations in the first place, and I think the same can be said about coding standards.
While some of the coding standards found using ESLint can be fustrating to correct, I think the “silver lining” of the situation is that this is the result of someone else’s bad coding experience, and is there to ultimately prevent the user from producing bad code that might not work. Someone else ran into the issue of not specifying a type, or a line-break causing an error to happen, and they had to scrounge through thousands of lines of code to find the error. We, as users of ESLint, just get to reap the benefit of that unfortunate situation and have the issue pointed out to us before we even reach that far into the code. For others, that might just be the insight needed to get through with accepting the help its providing, but from a personal viewpoint, I think there’s more to coding standards than just using it as an “auto correct” function.
One week to change my impression
After my first week of using ESLint with VSCode, my impressions went from fustration to coming to a point of understanding. At first, getting rid of all the ESLint errors felt painful: Everything I typed was immediately followed by the dreaded “red underline”, pointing out all these “mistakes” I made, even if all I did was write the name of the function. It slowed me down, caused me to question every little thing, and annoyed me when things like simple line breaks “shouldn’t” be breaking the code.
As we got closer to the end of the week, while the irritation hasn’t completely subsided, I am starting to see why certain callouts have been put in place, and have grown to be more understanding of the standards its setting. ESLint caught more than a few logic errors that I would have never seen or understood until it was too late, and some of those same early warnings serve as gentle reminders to think about the code I’ve been writing. It’s evolved from something that just told me I was wrong to a tool I could use to write better code, and its starting to work.
I feel as though I’m starting to anticipate some of the issues that I know ESLint will have with the things I write, and actively work to avoid it. The remaining red underlines act as a way for me to gain more insight on a topic by looking at its suggestion, or researching why its viewing the code as an error. All the while, I’m starting to internalize some of the structures of code for not just specifically Typescript, but also how to logically approach each individual problem. It’s helping me to be a better software engineer as a whole.
It’s now my safety net
In the end, I don’t see coding standards as just an arbitrary rule set by someone else to make the code look a certain way, I see them as guardrails. They don’t stop you from developing and creating code, but they do stop you from getting an unwanted outcome from your code. Tools like ESLint feel strict at first, but that strictness has helped to create opportunities to learn, develop, and produces code that is easier to read, reason about, and maintain. And that is worth all the pain of addressing that dread red underline as many times as needed.
Note on AI usage:
While writing this technical essay, Grammarly AI was used to help verify and check for all major grammatical mistakes.