Cutting corners is something that I love to do. Sometimes it is just a pain to make things look presentable when there is a faster solution. In computer science and coding, almost the same rules apply. Emphasis on almost. Programmers love to also cut corners, the lazier way is the most efficient way after all. However, it is the specialty of coding standards that allows programmers to be able to shorthand much of the code while still allowing it to be read legibly by other programmers. This is something that I’ve come to learn through my years of studying computer science.
Coding can be similar to taking notes, where it would be totally fine to write in a chicken scratch manner so long as you can read it, but once you give it to another person, they begin to question whether you were properly taught to write at all. In turn, programming is similar; other programmers need to be able to look at my code and be able to understand what is happening. If they see my chicken scratch of code, then it would be hours of deciphering hieroglyphics than working on a programming project.
What I have learned about coding standards and coding styles is that it is not just a template, but a learning experience. Enforcing a coding standard helps to personally recognize syntax errors and helps to clean up code to make it more presentable, that way other programmers won’t see my code as chicken scratch. Following the coding styles helps me to slowly see ways to not only cut corners and shorten my code, but also make it understandable and easy to read for others.
When it comes to coding standards and proper coding styles, keeping it clean and tidy is for future reference and usually not about the moment. During the creation of the source code, my head will be shifting gears and blowing steam, and my only intentions are to get my thoughts processed into IDE. However, when the gears finally get jammed and I need to take a well needed break, I would get disappointed to see that my code many hours later to be greeted by a brick of text.
Using ESLint in Intellij has really been that little voice in the back of my head to remind me that my code needs to be neat now so that I don’t have to worry later. What’s worse than having to stress over finishing code, is having to stress about tidying everything up after everything is done. While it is definitely annoying in the moment of writing the code to see so many red lines and ESLint errors, it is very easy to cleanup afterwards, as well as start to shift my own coding style to something that is naturally readable.
There is also a certain feeling of motivation to strive to create coherent and readable code without having to rely on ESLint to tell me what to change. This muscle memory of writing code with a coding standard in mind is very calming and allows me to focus more on the content of the code rather than the structure of it. Especially when it is a critical thinking period of code creation, I do not want to be wasting any of my energy worrying about if I missed a semi colon somewhere in the 60 plus lines of code that I just written. This has been something that I along with many others can agree on, that it is the minor subtle syntax errors that get the better of us rather than the bigger portions of the code.
The hours that I have spent wondering why my code would not work being chalked up to a where’s waldo style of finding where I am missing a end bracket or a semicolon. However! Now with the help of ESLint, and the enforcing of a coding standard, I have had a easier time to focus on the what needs to be done and did not have to worry about cleaning up my code before sending it to someone else to see. Overall, coding standards may seem like a tedious pain at first, but the more and more you use it, the more practice it is to write clean code and to keep a clear head.