Matt
My feedback
3 results found
-
1 voteMatt
shared this idea
·
-
48 votes
An error occurred while saving the comment An error occurred while saving the comment Matt
commented
I prefer having suppressions inside source code, at the very location where a potential issue originates. Things that belong together shouldn't be torn apart.
Matt
supported this idea
·
-
1 voteMatt
shared this idea
·
There actually are three kind of "broken" inhibitions:
a) Those no longer supported by a new version. Lint should warn about them.
b) Those that no longer apply because the code got refined or lint got relaxed. These would be nice to be reported. But:
c) Those that don't apply to a given project configuration but apply to another! Could lint possibly distinguish these from b)? Wouldn't lint need some kind of multi-configuration option where all potential project configurations with all their settings (symbols, include paths, exclusions,...) are linted at once to achieve this? Maybe we have to accept this hardly is possible. Or just possible for projects with a single configuration. And finally keep 3rd party headers in mind, they have to suppress any issues, as they don't know the lint project options of its customer projects.