From: John Femiani (JOHN.FEMIANI_at_[hidden])
Date: 2007-10-18 20:02:39
> > //@ignore_rule L001
> I agree on this with some previous post: I don't think that is a good
> option, mainly for two reasons. First it implies adding comments in
> to control some external tool, second if you start that path, you'll
> with a comment to control how vi indents, emacs options, vera++
> another tools options...
Line numbers change a lot when files are edited so how would an external
file deal with line-by-line exclusion?
Also if one of the points of an analysis rule is to help enforce a
convention, isn't _also_ nice to show in the source that you
deliberately chose to break convention?
If this is one of those never ending controversies that is cool. I just
personally like in-lining stuff (like using doxygen).
BTW a Vera++ rule exclusion does not seem like vi or emacs preferences
as I understand it. Somehow analysis rules, especially where they are
broken, seem like they are an important part of the code itself. If a
rule should be excluded from a part of a file, that is not just a matter
of one users preference. Maybe the better analogy would be pragmas that
enable or disable compiler warnings in a source file (VC8), or the
inline structured comments allowed by doxygen.
Also I was trying to follow the convention I have seen in eclipse, which
uses inline comments for Java. (I don't know what the underlying
analysis tool being used was)
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk