I think coding style refers to how you write code, including the way you name variables and solve problems. I agree that there are some standards common to all programmers, making it easier to read code written by others for the first time. I don’t believe there should be a strict set of rules that everyone must follow, but rather a set of guidelines to improve code readability. People should not overreact if someone does not follow the same code standard. I believe well-written code is code that is readable and understandable without having to talk to the coder. If you encounter poorly written code, it can be frustrating not to understand it and have to ask for clarification. This can make you appear ignorant just because someone has a very poor, inconsistent, and confusing coding style.
I don’t think coding style is a good way to learn a new programming language. Learning a new language involves understanding its syntax for variables, data types, dynamic typing, and function definitions. Some may argue that coding style is a good way to learn a new language because it aligns with industry practices. For example, using let instead of var and using const for arrays in JavaScript to align with industry standards. However, I don’t see it as an issue if your code differs from industry standards. As long as the code works and is readable and understandable, it’s fine. We shouldn’t worry about our code looking different from our peers as long as it meets these criteria.
Using inspectors like ESLint is a good way to check if your code meets coding standards. I find it useful but sometimes annoying because it can be very particular about things I consider unnecessary. For example, it insists on specific spacing around parentheses and brackets and requires extra blank lines at the end of files. I don’t see a problem with regulating the amount of spaces around operators; it just makes the code look cleaner and less cluttered. I like that ESLint offers simple fixes for coding standard errors, which I use frequently for ease of use. I usually write my code first and then go back to clean it up and fix all ESLint errors after confirming that it works. I appreciate that the linter provides helpful hints to simplify and improve code readability that I might not have thought of. For example, if I use an if statement in a method that returns true if the condition is true and false otherwise, the inspector might suggest simply returning the result of the condition, making the code simpler and easier to read. Overall, I like inspectors that provide hints on alternative approaches, but I dislike when they overly criticize simple coding standard syntax.