4 ms·
I believe the linter is the important part here. I've come to the conclusion that style guides are only useful if they come with a linter that fails builds. It'
by kevan 11y ago
I believe the linter is the important part here. I've come to the conclusion that style guides are only useful if they come with a linter that fails builds. It's way too easy to put code into a repo that works but doesn't live up to the style guide and once code hits trunk it's a lot harder to rework it.
- matt_wulfeck 11y agoI'll go you one further and say it shouldn't only be optionally enforced, it should just happen. The less I have to think about style the more I can focus on design. In the future every new language should come with a "go fmt" equivalent.
- kevan 11y agoAuto-formatting is great, but it can't handle everything. For example, our ESLint config prevents modification of function params[1]. I don't think a tool could automatically reformat this into compliance without changing the behavior of the code, a human needs to look at the failure and change it. [1]http://eslint.org/docs/rules/no-param-reassign.html http://eslint.org/docs/rules/no-param-reassign.html
- matt_wulfeck 11y agoThat's a ultimately a "problem" with the initial language design. If you design it with the intention of using auto formatters you won't run into these issues. I originally didn't like braces in go, but then I realized there's just enough in there to make auto-formatting easy.
- 50CNT 11y agoI think language design may be too strong a term for a lot of web technology. That's where you want to be using a linter and/or validator though.
- steveax 11y agoYep, also when there is an agreed upon linting config, the tooling becomes the "bad guy" on pull requests and lets humans comment on non-trival things.