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.

Answer 1

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>

Answer 2

You could take a look at 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.

Thank you for the interesting example!