HN Explorer

Ask HN: Why should I enforce code style?

5 points by dmtroyer ↗ HN
I’m leading a junior team of devs, and I’m trying to think of justifications for enforcing code style. Especially for minor things that have no functional difference.

Sub-question:

* If you are selective in your style enforcement, how do you do so objectively without angering others?

3 comments

[ 4.6 ms ] story [ 21.1 ms ] thread
davismwfl
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
This 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.

rvz
Well some of the reasons for enforcing a code style happens when if I have hired a new dev who also knows the style guide as mentioned in the job description (For example the LLVM C++ style guidelines). As soon as they are hired, they can contribute and can get up to speed with the source code changes quickly without too much hand-holding.

This is why Go,Rust,Swift, etc have built-in language specific formatters. C/C++ have cppcheck or clang-format to format to a defined style. Something like 'clang-format -style=llvm main.cpp'. With clang-format, it is possible to define your own coding style with this too.

Another use-case is when you have your own open-source library and you want external contributors to send patches. If it isn't written in a idiomatic style, then it would be seen as immature to use and so hard to read, only the creator can read it.

Enforcing a code style also helps with code reviews for clean patches. But this use-case happens with open-source projects but still applies to closed-source ones.