Cheers,
Running a static code analysis on a C# solution, I find the warning CA1006 "Do not nest generic types in member signatures" in various parts of the code where a generic type is used to pass it as an argument to a Func that is inside. from an Expression:
IEnumerable<T> GetForMe(Expression<Func<T, bool>> filter, IEnumerable<T> entity);
The signature above is part of a generic interface where T is the generic type.
The warning message is clear to me and looking at the documentation it makes a lot of sense that the warning appears and more so if its category is "Design".
However, I can't find a "fancy" way to "change the layout" of these signatures. Most of the places where this warning is cited say that it is better to omit it with the attribute [SuppressMessage]
.
In the microsoft documentation at: https://msdn.microsoft.com/library/ms182144.aspx it says:
Do not suppress the warnings in this rule. Providing generics with a syntax that is easy to understand and use reduces the time required to learn and increases the speed of adoption of new libraries.
Regardless of whether I suppress it or not, I would really like to know what would be the best way to adjust the layout of the signature.
Thanks.
I think that in your specific case it is justified to override the warning.
Expression<Func<T, bool>>
It's a usage pattern that's everywhere, so I don't see it as a design flaw in your API.This sounds very nice in theory. But in practice, even Microsoft doesn't always follow this rule. So don't worry if you have to suppress the warning in certain places.
For example, I think the vast majority agree that LINQ is both extremely powerful and expressive, and that it has been a tremendous improvement to the .NET library. However, when we take a closer look at the LINQ API, we can see that it does not respect the CA1006 rule at all.
A concrete example of this, which is very similar to yours, is found in IQueryable.Where() , whose definition is:
Obviously, this example does not respect the CA1006 rule. But would anyone doubt that it is designed correctly? Never!