Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I like the idea behind this because I am also very sensitive to that type of things. Probably over-sensitive but I just worry that if you let one thing go, it becomes a slippery slope and you then have a mess of a repo.

That being said, if you care about these things, I wonder if these checks are best left to a pre-commit hook. It removes noise from the commit history and the PRs and forces people to think about it right away, rather than being corrected after the fact.

I guess having that done on a server has the benefit of not having to worry about keeping the linters' version up-to-date/homogenous over all the devs' machines.

At work, we have JSCS (https://github.com/jscs-dev/node-jscs) and SCSS-lint (https://github.com/causes/scss-lint) as part of our pre-commit hook (on top of editor plugins) and that has been great honestly. It decreased the PR noise a lot and I feel it has been good for new hires since it avoids having the first PR comments being about style issues.

I wrote a post about how I added JSCS in the pre-commit hook by the way: http://tech.adroll.com/blog/web/2014/03/05/adding-jscs-to-yo... It should be easily extendable to other linters.



This question comes up often when I tell people about my project Landscape (https://landscape.io), which is similar to this except that it is for Python.

My argument is that often, especially on a large existing codebase, you'll get thousands of warnings and in that case, having the trends over time is useful as a way of measuring progress. The relative change is more important than the absolute value.




Consider applying for YC's Winter 2027 batch! Applications are open till November 2.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: