Facebook Open Sources flint, a C++ linter written in D

It amazes me how far out of their way many people will go to avoid using parsing tools.<p>He avoided using a lexer generator because &quot;I&#x27;d figured using a lexer generator was more trouble than it was worth&quot;. To him it was more convenient to write a lexer manually (using macros) in C++, then later completely rewrite it in a different language (D) as a one-off trie matcher code generator.<p>I am amazed that this could be thought of as less work. How can writing two lexers from scratch manually be less trouble than writing a bunch of regexes in a Flex or Ragel file? Especially since the result was likely slower than using Flex or Ragel would have been?<p>To me the interesting question is: how much of this allergy to external tools is:<p>1. the trouble of learning&#x2F;maintaining something new&#x2F;different (inherent tool overhead)<p>2. design of the tool isn&#x27;t as user-friendly as it could be (incidental tool overhead)<p>3. irrational belief that the tool will be more work&#x2F;trouble than it actually is (non-optimal decision making)<p>If part of the answer is (2), then improved tools will lead to greater adoption. And hopefully more convenient tools will lead to them being better known and more widely adopted, which should lessen (1) also.<p>Everyone uses regexes; using a lexer generator should (in my opinion) be as easy as using a one-off regex. I think the key is to make the lexer generator an embeddable library like regex libraries are.

Once you get used to tools like `go fmt` or Perl::Tidy it feels barbaric not to be able to cleanly format all your code instantly. Read only linters are nice but something that can reformat code is much nicer.

Years ago I remember learning template metaprogramming in C++ from an amazing book [1] from the same author of this tool. Even if looking back, I now think template metaprogramming when over-used may be a little bit over the top, I nevertheless have no doubt judging by his author that this new tool must have some very good qualities.<p>[1] <a href="http://en.wikipedia.org/wiki/Modern_C%2B%2B_Design" rel="nofollow">http:&#x2F;&#x2F;en.wikipedia.org&#x2F;wiki&#x2F;Modern_C%2B%2B_Design</a>

I&#x27;m a little skeptical that it doesn&#x27;t use a standard parser like clang. My gut instinct, from experience with crappy c++ &quot;parsers&quot;, would be that it works great 95% of the time, but fails the 5% of the time when it&#x27;d be most useful.<p>On the other hand, given the author, and the fact he explicitly mentions wanting to support C++11, I&#x27;m not sure my skepticism is warranted.<p>I wonder if anybody&#x27;s tried it on a big C++ code base outside of Facebook?

I chuckled at this passage: &quot;flint is written in the D language, making it the first D codebase open-sourced by Facebook. In fact, our initial version of flint was written in C++; the D rewrite started as an experiment. From the measurements and anecdotes we gathered, the translation turned out to be a win on all fronts: the D version of the linter turned out smaller, dramatically faster to build, significantly faster to run, and easier to contribute to.&quot;<p>Seems like the argument is stronger to rewrite the code being linted, than to use the linter itself ;-)

GitHub repo: <a href="https://github.com/facebook/flint" rel="nofollow">https:&#x2F;&#x2F;github.com&#x2F;facebook&#x2F;flint</a>

&quot;Even now, clang cannot compile some of our C++ codebase.&quot;<p>Andrei, I&#x27;m a bit surprised by this statement. Could you give an example?<p>Otherwise great work.

I am surprised how short the tokenizer is. The other thing is D looks surprisingly approachable coming from C++.

To me, this is more a proof of concept implementation in D than a tool I&#x27;d consider having part of my workflow. The dependency chain and &quot;exotic&quot; language choice makes just having it available in your ecosystem a higher jump than what utilities like linters should require.

This looks really good. Having checks like this integrated and automated is the big win. Like data backup, if it&#x27;s not automated then it doesn&#x27;t really count.

&gt; Marking namespace-level data as static inside a header is &gt; almost always a bad idea.<p>Can anybody explain this to me with some example?

I&#x27;m going to the D conference!!! :-)