Coding With Standards
06 Feb 2026
More Than Just Formatting
I thought coding standards were mostly just about appearance. Indentation, quotation style, brace placement - things that felt cosmetic rather than meaningful. After working with ESLint for a week, I realized that coding standards are less about aesthetics and more about discipline. They shape how you think about code, not just how it looks.
The biggest surprise, and probably the most pleasant one, was how often ESLint flagged issues that were not about formatting at all. Warnings about unused variables, unsafe comparisons, and inconsistent return behavior exposed habits that could easily lead to bugs. These were not munor stylistic preferences. They were guardrails that prevented fragile code. Fixing them forced me to slow down and understand why the rule existed in the first place.
Painful at First, Useful in the Long Run
At the beginning, clearing ESLint errors felt frustrating. During timed WOD exercises especially, it felt like the tool was fighting me. I would solve the problem logically, only to spend extra time fixing lint warnings before the code was considered acceptable. That friction made me question whether the standards were helping or just slowing me down.
But after several days, I started noticing a shift. I began anticipating the errors before ESLint even reported them. My habits adjusted. I started to learn to write cleaner variable declarations, safer comparisons, and more consistent functions. What felt like an obstacle at first is now turning into muscle memory. The tool stopped feeling like punishment and started feeling like guidance.
Coding Standards as a Learning Framework
I now see coding standards as a built-in teaching system. They act like a constant reviewer sitting next to you, quietly pointing out risky behavior. Instead of learning only when a bug appears, you learn in real time while writing the code. That immediate feedback accelerates understanding in a way lectures alone cannot.
For beginners especially, coding standards reduce ambiguity. Instead of guessing whether something is acceptable practice, you get a clear answer. Over time, those rules become internalized. You stop writing code to satisfy ESLint and start writing code that is naturally structured, readable, and safe.
If I had to pick one software engineering technique that improves quality the fastest, coding standards would be a strong candidate. They enforce consistency, reduce preventable errors, and create a shared structure that makes collaboration easier. Even when working alone, they make your future self grateful.
Clarity Over Creativity
Some people argue that coding standards restrict creativity. After this week, I see the opposite. Standards remove unnecessary decisions so you can focus on problem solving. When everyone follows the same conventions, code becomes easier to read, debug, and extend. You spend less time interpreting style and more time understanding logic.
That consistency is especially important in team environments. Code is not written for the computer - it’s written for other humans. Standardized stlye turns code into a shared language instead of a personal dialect.
Final Thoughts
After a week of ESLint, I would describe the experience as both painful and useful. The discomfort comes from replacing shortcuts with deliberate habits. The usefulness comes from the confidence that follows. I feel more intentional when I write code now. I’m thinking about structure, clarity, and safety instead of just getting something to run.
Coding standards are not trivial rules about whitespace. They are a framework for learning how to think like a software engineer. The sooner those habits form, the stronger your foundation becomes.
This essay was written by me with light ChatGPT assistance for organization and clarity.