How to fix violation of StyleCop SA1305 (Hungarian)

Question

My code contains a variable named "m_d3dDevice".

StyleCop complains about this name:

SA1305: The variable name 'm_d3dDevice' begins with a prefix that looks like Hungarian notation. Remove the prefix or add it to the list of allowed prefixes.

(Note I have manually disabled SA1308 ("m_"), one of the few rules I'm willing to disobey.)

I can't allow "d3d" as an exception in the Hungarian tab, as it only allows 1 or 2 char prefixes, and allowing "d3" didn't help. I've tried everything I can think of to add "d3d" to my CustomDictionary file (and anyway the docs imply the CustomDict isn't used for rule 1305).

Any suggestions to make StyleCop allow this one? It is a matter of pride now to not have to F2 my variable.

Demulcent

what is 'd3d' an abbreviation of? – Artemis

I think the only way to satisfy this rule is to rename your variable to something like m_direct3DDevice if that is what is an abbreviation for. – Artemis

What a ridiculous "rule" and an even more ridiculous litmus test to identify violations. What's wrong with just disabling that rule and trusting yourself to be smart enough to name variables? The blanket rule to avoid "Hungarian" notation has apparently gotten as ridiculous as the rule that one should use it. – Chestonchest

Cody: I'm sympathetic with complaints about SytleCop being so hard-nosed, as I've been also been bitten with variables like "m_d14" which make perfect sense contextually ("1/4th of D") but appear to be violations. sigh -mpg – Demulcent

Personally, I'd hate to mantain code that contains m_. – Contactor

Answer 1

You could take a look at my tool, StyleCop+. It contains flexible naming rules that will allow you to force all private fields be named starting with "m_" (or whatever you wish) instead of disabling name checking (like you did).

Regarding "d3dDevice" - it's a very interesting case. Logically, it splits to the following words - { "d", "3", "d", "Device" } or { "d3", "d", "Device" }. And the second "d" seems not to follow "camelNotation".

But I strongly believe that static analysis (particularly naming) should be flexible enough to satisfy user needs. Currently StyleCop+ can support your case in the following way - for example, you can add "exception" (as many as you want) to naming template for private fields, so that it will look like:

m_$(aaBb)
m_d3d$(AaBb)

This is more likely to be workaround, but I will think about your "d3d" case - and maybe StyleCop+ will support something like this.

Ire

Answer 2

You can also suppress stylecop on a case-by-case basis. e.g.

[System.Diagnostics.CodeAnalysis.SuppressMessage(
    "Microsoft.StyleCop.CSharp.NamingRules",
    "SA1305:FieldNamesMustNotUseHungarianNotation",
    Justification = "Using Win32 naming for consistency.")]
IntPtr hFile;

This might not be an attractive option if you have numerous offending names, but for one or two, it's generally fine.

Inverness

Answer 3

You can also use the Settings.StyleCop in the package files to configure the settings.

You can suppress specific words by adding below code to the Settings.StyleCop file:

<Analyzer AnalyzerId="StyleCop.CSharp.NamingRules">
  <AnalyzerSettings>
    <CollectionProperty Name="Hungarian">
      <Value>as</Value>
      <Value>do</Value>
      <Value>id</Value>
      <Value>if</Value>
      <Value>in</Value>
      <Value>ip</Value>
      <Value>is</Value>
      <Value>mx</Value>
      <Value>my</Value>
      <Value>no</Value>
      <Value>on</Value>
      <Value>to</Value>
      <Value>ui</Value>
      <Value>vs</Value>
      <Value>x</Value>
      <Value>y</Value>
      <Value>z</Value>
      <Value>iOS</Value>
      <Value>IOS</Value>
    </CollectionProperty>
  </AnalyzerSettings>
</Analyzer>

You can suppress the Hungarain Rule itself by adding the following to the Settings.StyleCop file

<Analyzer AnalyzerId="StyleCop.CSharp.NamingRules">
  <Rules>
   <Rule Name="FieldNamesMustNotUseHungarianNotation">
    <RuleSettings>
     <BooleanProperty Name="Enabled">
        False
     </BooleanProperty>
    </RuleSettings>
   </Rule>
 </Rules>
</Analyzer>

Crockett

Answer 4

Adding suppression attribute should be done on top of all methods which will take time and a long process.

If you would like to remove this rule from your project try this

• Right click on your project
• Select Stylecop Settings
• Find SA1305
• Uncheck the rule from result set
• Click Apply - OK
• Rerun style cop rules again.

Lorant