Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

Gendarme: Add support for glob-like '*' in the ignore file syntax #16

Open
wants to merge 5 commits into
from

Conversation

Projects
None yet
3 participants
Contributor

krijesta commented Dec 13, 2011

This changeset adds support to Gendarme to allow glob like "*" matches to be used in the ignore files.

The * can be used in any of the fields (other than Namespace) allowing either a single rule to easily be ignored in a variety of positions or multiple rules in a single location.

An example of this use would be to ignore the AvoidUncalledPrivateCode rule in any Type in "NUnit" or "Test" namespace, as the test functions can be private, and are called through reflection - having to add a new entry each time you add a new unit test would just be annoying.

krijesta added some commits Dec 12, 2011

Update IgnoreFileList to support '*'
This should allow glob-like matches of * for all of the entries other
than namespace in the ignore file
Only use regex if needed
Without this parsing a long ignore file takes significantly longer than
previously
Updated self-test.ignore to use "*"
This shows an example of when a * can be used to vastly simplfy this
sort of file
Owner

spouliot commented Dec 15, 2011

I like the idea but I need to test the performance impact of this. Historically everywhere we used Regex and LINQ in the "hot path" turned out to slow gendarme operations a LOT (e.g. a single rule taking as much time as 200 other rules). I'm a bit busy at the moment but I'll test this during the xmas break. Thanks!

Contributor

krijesta commented Dec 16, 2011

Without 5d7ad0a (Only use regex if needed) there was a significant slowdown however after doing this the time difference on my machine wasn't noticeable for the Gendarme self test - but I don't have numbers so can't quantify that.

Given that there was this slowdown I imagine that a large ignore file with lots of *s in it would be slower - but that the slowdown should only ever be an issue if you are using wildcard matches.

If the slowdown is an issue I'm sure a far more efficient matching scheme could be written given that we are only using Regex to do a simple glob match which would achieve the same thing without the cost

Contributor

krijesta commented Jan 10, 2012

Just got back to work so I've run some quick timed tests - although still not real profiling.
Average times to run the self-test over the gendarme bins:

before this change: 3.7s
After the change with the old selftest.ignore file (containing no *'s): 4.0s
After the change with the new selftest.ignore file (containging the few *s and far fewer lines): 3.9s

So the slowdown is not insignificant but I think that the benefits outweigh it - files with a large number of *'s in would be slow to parse - but should not exist, these *s should only need to be used in a limited number of places.

Sup guys :)

Sorry to dust dig this out from the abyss of 2012. But since I was looking for a similar functionality and I stumble upon this PR.

Is the project still active? Are you considering merging this PR?

Cheers,

-Sam

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment