cloc counts "#if 0" lines as code

[fefe17]

When running cloc against some code of mine, I noted that it does not appear to have any support for the C preprocessor.

It's a well known idiom in C to comment out large chunks of code by adding an "#if 0" at the start and an "#endif" at the end. cloc counts all that lines as code.

I would also like to give cloc regex for detecting unit tests. In my code, for example, there is an #ifdef UNITTEST ... #endif in every file that unit tests. To run the tests, you do

$ gcc -o t file.c -DUNITTEST && ./t

As with all good unit testing, I have mode lines of unit tests than I have lines of actual code. I would like cloc to either count those as comments, or, preferably, add a new category besides comments and code.

[AlDanial]

It's an interesting idea but I don't see how I'd implement it in cloc. The behavior you're currently seeing is mentioned as item 6 of the Limitations section of the docs. cloc is regex-based and there's no regex I know of that can associate an #ifdef with its paired #endif.

If you can think of a way I'll consider it, otherwise will have to decline.

[xparq]

Footnote:

What actually counts as code can be use-case dependent: I may want to include all available code, or maybe I only want to see live/active code. The tool alone can't reliably guess, so this should be optional.

Related is whether to even count comments as "code": e.g. commented-out code can still be considered code (depending on the use case), only disabled temporarily (just like with #if 0).

Footnote to the footnote:

In fact, I'm usually interested in the lines of comments in general + code together, as "source material", in the spirit of Knuth's literate programming. (Note that (good) comments recording intent are even more important than the code itself, as code can be reproduced from those, but reverse-engineering intent from code is inherently lossy (as the code of evolving (i.e. not dead...) software is often sloppy/incomplete/buggy.)

Another reason I almost never count comments separately is that the overall extent of the "source material", e.g. as the amount of human work done is almost always a more interesting source metric to me than the number of code lines the machine would see, as its own amount of work. That's more like the realm of benchmarking instead.

(It's a blurred line, though, so (again) the user should be able decide. Hence, I always add --fmt=2. I wish that was the default from the get-go, though. I understand it's not possible to change now, breaking all the scripts out there. In fact, I'd probably prefer a --raw option for code + comment + blank (equivalent to wc -l) for a clear canonical baseline metric.)