Boost logo

Boost :

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
the
> code
> to control some external tool, second if you start that path, you'll
end
> up
> with a comment to control how vi indents, emacs options, vera++
options,
> another tools options...
>
> David

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)

-- John


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk