Skip to content

Conversation

@ellismg
Copy link
Member

@ellismg ellismg commented Apr 17, 2020

As a follow up to #11414, I was trying to understand why did not see
errors from the "FxCop Analyiszers", which would have pointed out that
issue to us.

The reason was simple - we had disabled the analysis for these projects.

I've re-enabled them, either fixing up issues or adding suppressions.
We ended up catching some reasonable errors (a few cases where we called
the ArgumentException constructor but messed up the order of the message
and the parameter name) as well as a case where we were passing two
parameters to an internal method but then disregarding them. In
practice, the code we had was still "correct", because it happened to
only be called from a single place today and the only caller was passing
the same values that the implementation was actually using.

Overall, I think taking this would be worthwhile. It brings this library
back in line with the the others. I could imagine some library wide
supressions of rules here, specifically the one about not calling
virtual methods from constructors, since in practice we are unlikely to
hit the problems the rule intends to guard for, but for now I've just
made the diff look "as bad as possible" by doing supressions around the
offending lines with justifications.

@ellismg ellismg requested review from jsquire and kinelski April 17, 2020 23:42
@ellismg ellismg requested a review from serkantkaraca as a code owner April 17, 2020 23:42
@ellismg ellismg force-pushed the ellismg/enable-fxcop-for-eventhubs branch from a16a712 to 5373398 Compare April 17, 2020 23:49
Copy link
Member

@jsquire jsquire left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks for kicking the tires on this. The analyzer spam seems far less plentiful than the last time we thought to try and enable it. Not a fan of the #pragma blocks that we need, but I'd agree its the lesser of evils.

As a follow up to Azure#11414, I was trying to understand why did not see
errors from the "FxCop Analyiszers", which would have pointed out that
issue to us.

The reason was simple - we had disabled the analysis for these projects.

I've re-enabled them, either fixing up issues or adding suppressions.
We ended up catching some reasonable errors (a few cases where we called
the ArgumentException constructor but messed up the order of the message
and the parameter name) as well as a case where we were passing two
parameters to an internal method but then disregarding them. In
practice, the code we had was still "correct", because it happened to
only be called from a single place today and the only caller was passing
the same values that the implementation was actually using.

Overall, I think taking this would be worthwhile. It brings this library
back in line with the the others.  I could imagine some library wide
supressions of rules here, specifically the one about not calling
virtual methods from constructors, since in practice we are unlikely to
hit the problems the rule intends to guard for, but for now I've just
made the diff look "as bad as possible" by doing supressions around the
offending lines with justifications.
@ellismg ellismg force-pushed the ellismg/enable-fxcop-for-eventhubs branch from 5373398 to 58fc47a Compare April 21, 2020 23:55
@ellismg ellismg merged commit f07295c into Azure:master Apr 22, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants