Option to recurse over all .cpp, .c, .h files in a directory

[Andrew Pennebaker]

I'd like to drop a simple command like vera++ . in all my C/C++ projects, but vera currently doesn't know how to look for code files in a directory.

Could we please add an option to have vera look for all .cpp, .c, and .h files recursively in a directory?

As a workaround, I'm using make and find:

vera++:
    find . -type f -name '*.cpp' -exec vera++ -e {} \;
    find . -type f -name '*.c' -exec vera++ -e {} \;
    find . -type f -name '*.h' -exec vera++ -e {} \;

[Gaëtan Lehmann]

That could be an interesting improvement of the command line interface. Could you suggest a way to write the command line to use that feature?

[Andrew Pennebaker]

Are you asking for implementation or usage?

[Gaëtan Lehmann]

I was thinking to usage -- what a command that use that feature would look like.

And of course I would welcome an implementation as well :-)

[Andrew Pennebaker]

vera++ could check filename arguments to see if they are directories. If so, recursively run vera checks over each child file. Hypothetical usages:

$ vera++ cool-c-project/ cool-c++-project/
$ vera++ lib/
$ vera++ .

This is how JSHint works, for example.

[Gaëtan Lehmann]

I'd prefer to have an option for that, so we can issue a error or a warning when the user tries to pass a directory by mistake. --recursive with ?-r or -R as short option would have been nice but as you said, they are already used. What do you think of --find and -f?

Unfortunately, there are a lot of file extensions used for c++ code (.h, .hxx, .cxx, .cpp, and probably many other). The command line should allow to pass which file extensions to use.

CMake does this kind of thing by putting the globbing expression at the end of the directory path.

vera++ --find 'my-great-project/*.{hx,ixx,txx,cxx}'

This may not be that convenient in real use though because it would force the usage of the quotes to protect the globbing expression from extension by the shell.

We could also use a --find-extension or -F that allows to change the file extensions found. By default they would be .h .hh .hpp .hxx .h++ .cc .cpp .cxx .c++ (source http://en.wikipedia.org/wiki/C%2B%2B)

vera++ --find my-great-project/ -F hxx -F ixx -F cxx -F txx

[Andrew Pennebaker]

What if we provide a long option for now, --recursive <directory>, that checks .h, .hxx, .cxx, .c, and .cpp files?

[Jacobo Domínguez]

The proposal from Andrew (4 years ago :)) will be great!

[Thomas Lerman]

Agreed. As stated, I would love to be able to find all .c, .cpp, .h, etc. from a specified directory and recursively. It would also be great to ignore certain directories (e.g. release/*) and files (e.g. Qxt*.h). The would be nice to be available through the command-line and/or through a config / suppression file (similar to cppcheck)

[Andrew Pennebaker]

As a workaround, I have bundled some shell code into a reusable executable:

https://github.com/mcandre/sail

This shim works with other linters as well. Apologies if I missed any fringe file patterns.

But a complete solution with directory recursion built into vera would be preferable.

[Thomas Lerman]

Thank you for posting that. I wish I would have thought about posting before I created a Windows batch file using Powershell, which is a pain. The following is used as an example of getting all *.h and then removing some that I might want suppressed. It would get repeated for other file types:

@powershell "Get-ChildItem -Recurse .\*.h | Resolve-Path -Relative | findstr /v /c:"release" | findstr /v /c:"debug" | findstr /v /c:"protobuf-c" | findstr /v /c:"glext.h" | findstr /v /c:"stdint.h" >> veraFiles.txt

It would get repeated for other file types and then changed into the right format:

@powershell (Get-Content "veraFiles.txt") -replace ('\.\\') >> veraTemp.txt

Then use it within the command-line:

vera++ --summary --show-rule --profile default --inputs veraFiles.txt > vera++.txt

‌

[Andrew Pennebaker]

By all means, do post PowerShell snippets!

For this and plenty of other projects. As much as I enjoy UNIX shells and WSL, it is of practical value to provide a native Windows equivalent and vice-versa wherever possible.