-
Notifications
You must be signed in to change notification settings - Fork 32
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
LC0035 - false positive for fields that aren't enabled #369
Comments
The same applies for fields that are Obsolete. At least with I'm not sure what's the best approach for |
Thank you for the feedback, both points are valid and are indeed false positives. The updated prerelease (same version number) should address both For now I'm not validating the value of the |
I believe that fields with |
I don't think there's a right answer for this question. @jwikman, you're absolutely right about the pending for quite a while, but then again this property should already has been set when creating the field? But then we could discusses the use case on creating and new field and obsoleting the old one, then I would indeed like to raise that warning to be honest. For consistency throughout the LinterCop, where all rules exclude pending and/or removed objects, I would like to apply the same here. It could becoming confusing when obsoleting the whole table versus obsoleting a single field. The LinterCop skips almost all rules when the object has a ObsoleteState property (regardless of the value). |
True, we've got two scenarios - when we get this new rule on existing code, and when having this rule when writing new code. I was thinking about the first scenario - I would like the warnings on all fields, regardless of ObsoleteState "Pending" or not, when the rule applied on an existing project. :) And I think you are right to do the same in other rules (haven't thought through all of them, though 😉). I hope I don't get to regret this... 😅 |
We sometimes have fields on tables, that are there only as dummy fields to ensure that TransferFields won't be crashed by creating a field in a sibling table with a different type.
Those fields are having the property
Enabled=false;
Those fields shouldn't trigger the info for Rule LC0035.
The text was updated successfully, but these errors were encountered: