4 ms·
Coding standards help for readability, maintainability and reduce defect rates when done properly. At first every coding standard feels a little like big broth
by davismwfl 7y ago
Coding standards help for readability, maintainability and reduce defect rates when done properly. At first every coding standard feels a little like big brother trying to force you to do something that has little value. But in the end it has a lot of value to the overall team because it equalizes the code.
Anymore the easiest way is just setup the standard IDE profile for the language and make sure everyone uses it. This removes 80% of the work and makes it easy for most people. I also like this because I personally have some ways I like code that are contrary to what a lot of people like, so when I setup the IDE it makes it easy for me to stick with the standard versus what I might want to do since it is more work to change it. I found this to be true for most engineers as well.
Overall, I don't like the idea of huge coding standards however, unless the project is a vital system. For example, with embedded devices I like a more strict coding standard because the cost of errors are much higher, but for web I find more lax coding standards acceptable because the risk is usually lower in terms of cost and time. However, the web argument changes when you say there are millions of users of the software, then standards become crucial to quality and reliability.
In the end it comes down to cost to maintain the software and fix defects, standards lower that cost so they are the right thing to do.
- 867567838694 7y agoThis pretty much nails it all. Good shared coding standards are like not throwing trash on the beach when you leave. It about more than "you". I have also seen coding standards taken too far as well which can almost have worse side effects so be mindful. Personally for my Javascript projects I've been using prettier with their combined linting rules. I don't like every choice it makes, but it keeps the code clean and consistent. I also like to make sure the team is down on all the rules you can't auto-format and I like to keep those light. Use es6, no lodash, use native promises, don't use arrow functions to define class methods... that kind of stuff, all very personal and project specific.