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

Additional cases where uses of integers are clearly not magic #4625

Closed
wants to merge 1 commit into from

Conversation

@StingyJack
Copy link
Author

An additional possible case is present in https://referencesource.microsoft.com/#system.web/Security/SQLMembershipProvider.cs,1039

I had been porting some of this to .net core and because the stored procedure returns a selection of variables, the resulting field names in the SqlDataReader are all "" and the values can only be retrieved using an index. I dont know whats worse, leaving it as it is, or creating a bunch of constants like const int ResultSetColumnOrdinal_Password = 0. Neither seem appealing.

Copy link
Contributor

@andrei-epure-sonarsource andrei-epure-sonarsource left a comment

Choose a reason for hiding this comment

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

Thanks @StingyJack

We've discussed internally and created an issue with the cases we'd like to cover: #4737

/// <summary>
/// A five minute sliding expiration
/// </summary>
public static CacheItemPolicy FiveMinSlide => new CacheItemPolicy {SlidingExpiration = new TimeSpan(0, 5, 0)};
Copy link
Contributor

Choose a reason for hiding this comment

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

indeed DateTime APIs could be considered as well-known cases. The problem is how to avoid having to maintain such a list, we would need to find something generic enough.

Copy link
Author

Choose a reason for hiding this comment

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

if parameter name is the name of a specific time measurement ("day" "month" "year", etc), then the usage of a literal has an obvious, specific, and easy to understand meaning and is thus not "magic".

Copy link
Author

Choose a reason for hiding this comment

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

The same would be true for "Order"

Copy link
Contributor

Choose a reason for hiding this comment

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

May be first go back to the drawing board, and think of what to support first?

Copy link
Author

Choose a reason for hiding this comment

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

@Corniel as a user of sonarcloud, I want it to report when a literal number has been used in a place where its not obvious what that number's meaning is.

Copy link
Contributor

Choose a reason for hiding this comment

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

@StingyJack I got that point. This a pull request. I saw that @andrei-epure-sonarsource already made an issue to discuss the fllow up: #4737

Copy link
Author

Choose a reason for hiding this comment

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

Then I'm not sure what you're looking for here from me

Copy link
Contributor

Choose a reason for hiding this comment

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

@StingyJack Well, I'm just a volunteer, but I would think that your input on what should not be considered magical numbers would help. As @andrei-epure-sonarsource andrei-epure-sonarsource mentioned, the challenge is to come with generic constraints, instead of some types that should be excluded, as the maintenance cost is high for those.

Copy link
Contributor

Choose a reason for hiding this comment

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

I initially asked for a PR with test cases on the community forum, hence this PR.
I will close this PR in favor of #4737.
Thanks @StingyJack for the discussion and this PR.

@andrei-epure-sonarsource
Copy link
Contributor

I will close this PR in favor of #4737.

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.

3 participants