Add linter for conventions and style

[travisbrown]

This may need to be a longer-term goal, but in my view providing a linter is one of the single most important things a project can do to promote contribution.

I definitely agree that we should be documenting conventions like #27, but having to parse a bunch of guidelines in prose (and then extrapolate from the current source when the guidelines aren't 100% unambiguous, which is always) can be stressful—I know that I'm personally a lot less likely to click the submit button on local work if I'm worried that it's going to be picked apart because I didn't understand all the details of the project's contributor guidelines (and that's even if I don't think the maintainers are going to be dismissive or condescending). Being able to go through a few rounds of local correction for formatting and convention before I put something in public is hugely confidence-building.

I like both WartRemover and Scalastyle, but I'm not sure either is a perfect solution to this problem.

[mpilquist]

👍 Scalariform would also be nice to standardize syntax.

[ceedubs]

👍 to Scalastyle and WartRemover (at least what we can enable - we probably will have some things like isInstanceOf for performance hacks).

Scalariform may be okay in this project, but my previous experience in a project that used Shapeless was that there was no permutation of options that would allow me to tell it not to reformat HList literals into an unreadable mess.

[non]

I think this is a good suggestion. My feeling is that we should produce a (relatively detailed) document explaining the coding style/standard for type classes etc. and then try to reify some of those guidelines in a linter tool.

Like @ceedubs I'm wary of code rewriting but if we can find a set of settings that doesn't mangle nice code I'm definitely open to it.

[coltfred]

👍 for Scalariform. Without some sort of automated code formatting tool it's really hard to tell if I'm conforming to style. Linter and WartRemover make builds glacial, but we've had really good success with having them in a different target which we run just before pushing.

[wedens]

automatic formatters is good only in simple cases. when you have some high-arity functions and parameters, formatter will create unreadable mess from it (as @ceedubs said).

[ceedubs]

I started a branch on my cats fork to add Scalastyle. It did a good job of catching some whitespace issues, but I ran into an issue. It uses Scalariform internally, which fails to parse Free.scala. I left more info in a commit message and will try to follow up when I get some time.

[non]

Fixed by #77