why microsoft keeps documenting code with constant like WM_SOMECONSTANT but the code analysis in Visual Studio reports the CA1707 warning?
Should we suppress all these warning for the solution? should we rename all the constants?
why microsoft keeps documenting code with constant like WM_SOMECONSTANT but the code analysis in Visual Studio reports the CA1707 warning?
Should we suppress all these warning for the solution? should we rename all the constants?
It looks like you're referencing a Native function in Windows. The recommendation here is to put the call to that function (and any enums and constants it needs) in a separate NativeMethods
class with its own .cs
file. That way it's easy to suppress the CA1707
in code for the whole file.
And it's recommended to not sprinkle your non-native code with all of these constants either, can you create a simple wrapper that acts as the bridge between the ugly native win32 API and how you intend people to use it in your C# app? That way the rest of the code can remain blissfully unaware of it.
A few tricks that may help here:
When using the new .editorconfig
style ruleset files, you can specify a naming convention for the files to which rules apply:
[*.{cs,vb}]
dotnet_diagnostic.CA1707.severity = warning
[NativeMethods.{cs,vb}]
dotnet_diagnostic.CA1707.severity = none
You can suppress inline with a compiler directive for a whole file:
#pragma warning disable CA1707 // Identifiers should not contain underscores
public class Class1
{
public string WM_ERSHSERHSEHRSER;
}
#pragma warning restore CA1707 // Identifiers should not contain underscores
You could move the native methods to a separate class library and disable the rule there altogether.