Your Standard, My Standard, the Standard
22 Sep 2024
The average experience of aspiring engineers
At some point in our journey of becoming a software engineer, we encountered many style of coding, some of which we’ve picked up along the way, and some that left us wondering, “Why?” The farther we walked down the road, the longer our habits became instilled in us, and only then, only when we’ve become comfortable of our own practices, does an entity come to deliver the message that we have been doing it wrong, and that there are standards that we need to follow if we were to continue walking the road. So, we fix it. We fix these habits of ours to follow these standards because this is the same road that had been ventured by experienced engineers. Then we go on our merry way, believing that everything is right with the world.
Yet, another entity walks up to us, and informs us of failing to meet the standard once again. So we’re left with the question:
“Is there a true standard?”
If there are no universal set of standards, is it important?
In my experience, I had been fortunate enough to be taught early on in my undergraduate career that there are no universal standard for coding. There are well-known conventions, such as Hungarian notation, but no universally implemented set of standards. However, setting and adhering to standards is crucial for every team, whether they are engineers, doctors, carpenters, or other professionals. Uniformity helps ensure that everyone stays on the same page and reduces uncertainty for new team members about how the team operates. Thus, while there is no universal standard for coding practices, being able to adapt to different sets of standards is important, as we will work with various teams throughout our careers as software engineers.
Current experience with ESLint
Such is what I tell myself as I muster through my software engineering class using ESLint. It has forced me to leave behind my preferred coding style that I had grown comfortable with, and adapt its coding conventions. As it has only been a week, the first impression it has left on me is how fussy it is! Left behind a space on an empty line? Error. Used double quotation marks? Error. Didn’t add a newline at the end of your file? Error.
If I were to install ESLint into a file I had previously made, a huge amount of red squiggly lines would appear, waiting for me to fix. It’s clear how uncomfortable that made me feel, revealing just how far my code had strayed from commonly used conventions. However, adaptability is key, and for my code to be easier to read by classmates and graders, it’s better to learn these new standards. Moreover, ESLint has taught me new tricks, like leaving trailing commas at the end of the last property. This reduces debugging in cases where I append a new property but forget to add a comma earlier.
While adhering to new practices can be troublesome, it exposes you to different styles and may even teach you something you’d like to incorporate into your own personal projects.