Matt

My feedback

3 results found

  1. 1 vote
    under review  ·  0 comments  ·  General  ·  Admin →
    How important is this to you?
    Matt shared this idea  · 
  2. 48 votes
    under review  ·  3 comments  ·  General  ·  Admin →
    How important is this to you?
    An error occurred while saving the comment
    Matt commented  · 

    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.

    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  · 
  3. 1 vote
    planned  ·  0 comments  ·  General  ·  Admin →
    How important is this to you?
    Matt shared this idea  · 

Feedback and Knowledge Base