OCLint

oclint.org

65 points·rayascott··7 comments

I have installed OCLint on my work codebase (iOS ObjC), and I love having the extra sanity check on code, but it does not compare in terms of power / performance / ease of use to either of the two other linters i've used, swiftlint and eslint.

My biggest complaint is integrating it with xcode is not great - it requires a second compilation after your regular build runs to generate the json compilation database it needs.

This is not the oclint team's fault, but it makes it frustratingly slow to use for every build - which is how linters should be used in my view.

I guess the immediate question everyone has for such tools is how does it compare with clang-tidy for C++?

Clang tidy has more style related checks. Where oclint is better at diagnosing complexity.

Saying that, I've recently felt like the development of clang tidy has been much more active and it will become the do-it-all tool very soon.

And, similarly, what about vs. clang static-analyzer?

Clang static analyzer is about checking logic errors - unused variables, memory leaks, etc.

OCLint does things like warn if there are too many non-comment-lines-of-code in a method, or too many methods per class. It's more about keeping tabs on complexity and code cleanlyness than true static analysis.

Ideally, use both! If you're using Xcode you can enable "analyze" for all builds. Highly recommended if it doesn't break your build times.

Clang static analyzer can be run as part of oclint run. It contains slower and more complex memory related checks.

IIRC, clang-tidy includes all clang-analyzer checks.

Reply on news.ycombinator.com