I’m sure you’ve heard this expression before, which is commonly heard when explaining that with practice, things become trivial and efficient. Coding standards are very much like this analogy in many ways. With practice, coding standards allow your code to have better readability for not only yourself, but others as well. This lets others figure out what code you’ve written, and also keeps things nice and clean for yourself to understand. These coding standards are comparable to the rules and laws of the road. We all go through drivers-ed where it is mandatory to learn all the necessary rules, to get on the road as a driver. These rules are in place to lessen confusion, and effectively accomplish their goals in an efficient manner. There are yellow lines on the road which are warnings, to make sure you are following the correct path. There are yellow lines under your code that you rushingly threw together. Both are warnings, to guide us along a road that is already developed for us.
I myself use ESLint, to correctly organize my code in IntelliJ. I usually have a bunch of warnings in my code, but it doesn’t bother me. The warnings I get are usually very easy to clean up, and are trivial things such as leaving a new line at the end of my file. Nonetheless, I love being able to look at code I’ve written long after I’ve forgotten about them, and still be able to quickly understand what I’ve written. Coding standards are not only a guideline but in some cases, a learning instrument. For example, when first learning a language, introducing a proper format will help a person recognize patterns more as they recognize code they’ve seen before. It helps a ton when the code is uniform and clean. Just like how I prefer my roads, and fellow drivers. Distinctly recognizable lines on the road, and other driver’s who follow them.