This is how it looks

From how I interpret the coding conventions, line length >80 should be a warning, >100 should be an error. Is that possible to implement with Vera++?

From how I interpret the coding conventions, line length >80 should be a warning, >100 should be an error. Is that possible to implement with Vera++?

You are right. This is not possible directly, but can be solved adding a riot-force profile (that contains critical stuff like line length > 80) and keep the riot profile with warnings.

Then, it's required to execute vera++ 2 times (one with warnings and the other one with errors). What do you think?

So vera complains but cannot not reformat automatically?

So vera complains but cannot not reformat automatically?

Yes it can. There are some default transformations we might use (trailing whitespaces, etc)

IMO uncrustify was a good idea. See #8519 (comment).

@jia200x @miri64 If we are willing to modify the TCL files, the warning on line length >80 and throwing an error on length > 100 should be perfectly possible.

Vera has only one "report" function, and it's up to the user to define a convention for report lines (something like Warning:/Error: etc). Then we can have two config values and have the script emit either a Warning or and Error.

Also, if I understand correctly, each script is run independently, meaning each file is traversed multiple times?

@jia200x I suggest we include a few example configurations for popular editors, so that people can run Vera/Uncrustify while they are editing the file. It should encourage people to not wait till the last moment to fix the source.

@jia200x @miri64 If we are willing to modify the TCL files, the warning on line length >80 and throwing an error on length > 100 should be perfectly possible.

Vera has only one "report" function, and it's up to the user to define a convention for report lines (something like Warning:/Error: etc). Then we can have two config values and have the script emit either a Warning or and Error.

True

Also, if I understand correctly, each script is run independently, meaning each file is traversed multiple times?

Not sure, but tend to think yes. I will check.

@jia200x I suggest we include a few example configurations for popular editors, so that people can run Vera/Uncrustify while they are editing the file. It should encourage people to not wait till the last moment to fix the source.

That's a nice idea. It's like what some editors do with PEP8 in Python. Pointing out errors is exactly a Vera++ job, because Uncrustify can only show the diff and not the reason (e.g line 294: extra empty line). However, it's possible to configure these editors to run Uncrustify with a user defined command.

Also, if I understand correctly, each script is run independently, meaning each file is traversed multiple times?

On second thoughts, I think it parses/tokenizes first and then run all scripts at token level.

However, it's possible to configure these editors to run Uncrustify with a user defined command.

My point is, if vim is so cool as it's followers claim it should be 100% possible to run Vera in "lint mode" (i.e. visually mark lines that are problematic). I don't use vim so I don't know.

My point is, if vim is so cool as it's followers claim it should be 100% possible to run Vera in "lint mode" (i.e. visually mark lines that are problematic). I don't use vim so I don't know.

Yes, it's possible

My point is, if vim is so cool as it's followers claim it should be 100% possible to run Vera in "lint mode" (i.e. visually mark lines that are problematic). I don't use vim so I don't know.

Should be possible, and I imagine, that popular linter-plugins like syntastic already provide a config for vera.

From the vera README:

Vera++ is mainly an engine that parses C++ source files ....

Looking at the API, though, this statement may be a bit exaggerated. AFAICT vera only tokenizes the files. Any parsing is done by the scripts with ad-hoc state machines (like

Looking at the API, though, this statement may be a bit exaggerated. AFAICT vera only tokenizes the files. Any parsing is done by the scripts with ad-hoc state machines (like

Yes, I think they refer to "interpreting" the C++ code into tokens. It's similar to what Uncrustify does

What is the testing procedure for this one with https://github.com/RIOT-OS/riotdocker/pull/49 ?

@cladmi I forgot to add it. Just updated it in the description.

For testing, run dist/tools/vera++/check.sh

I pushed the v1.2.1 files within the last commit, so it's compatible with the binary package shipped in Ubuntu

@smlng @aabadie @kaspar030 I just fixed an error with the check script and now static tests pass.
Can someone review again?

In theory this would be ready to be merged and would finally add some exhaustive lint checks to our C code.

ping

one minor note: in the profile file one cannot infer what a rule does just by its number, e.g. L004, one always needs to lookup the rule file and see code and comments there. Maybe add short comment in the profile which rules are active, e.g.

It makes sense. I will

@smlng done!
I also fixed added some param files (required by the old vera++)

(btw I couldn't add inline comments. They seems to be invalid in the TCL parser :( )

@smlng may I rebase?

yes please rebase (and squash if needed)

rebased and squashed!

@smlng all test passed :)

thanks! Can someone merge then? :)

done

thanks!

Hm did you check how many errors vera++ reports for the existing code?
It seems like new PRs are now required to clean up existing code if they touch files with style errors.

Hm did you check how many errors vera++ reports for the existing code?
It seems like new PRs are now required to clean up existing code if they touch files with style errors.

Hmmm if it's being a problem, maybe we can try to set them to warnings and fix those errors in parallel? Then we can re-enable Vera++ errors