Skip to content
New issue

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

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[EventHubs] Use Invariant vs Current culture #11414

Merged
merged 1 commit into from
Apr 17, 2020

Conversation

ellismg
Copy link
Member

@ellismg ellismg commented Apr 17, 2020

By default, the .Parse and .TryParse methods, as well as .ToString
use the current culture. In some of our uses, we don't want to the
behavior to differ based on the culture of the local machine.

By default, the `.Parse` and `.TryParse` methods, as well as `.ToString`
use the current culture. In some of our uses, we don't want to the
behavior to differ based on the culture of the local machine.
@ellismg ellismg requested a review from jsquire April 17, 2020 19:48
@ellismg
Copy link
Member Author

ellismg commented Apr 17, 2020

In practice, I'm not sure this actually matters because of the narrow scope of our use of these APIs. But this is reasonable hygiene.

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.

Thanks, Matt!

LGTM. We definitely should have been doing this already.

@ellismg ellismg merged commit 9b5aad3 into Azure:master Apr 17, 2020
@ellismg ellismg deleted the ellismg/use-invariant-culture branch April 17, 2020 20:12
ellismg added a commit to ellismg/azure-sdk-for-net that referenced this pull request Apr 21, 2020
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 added a commit that referenced this pull request Apr 22, 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.
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