Pregunta FxCop: la palabra compuesta debe tratarse como un término discreto


FxCop quiere que deletree Nombre de usuario con N mayúscula (es decir, Nombre de usuario), debido a que es una palabra compuesta. Sin embargo, debido a razones de coherencia, debemos deletrearlo con una n minúscula, por lo tanto, nombre de usuario o nombre de usuario.

Intenté ajustar el CodeAnalysisDictionary.xml agregando la siguiente sección a la sección:

<DiscreteExceptions>
  <Term>username</Term>
</DiscreteExceptions>

Por lo que entiendo cómo funcionan los diccionarios personalizados, esto debería decirle a FxCop que trate el nombre de usuario como un término discreto y evite que la comprobación CompoundWordsShouldBeCasedCorrectly (CA1702) active un error.

Lamentablemente, esto no funciona. ¿Alguien tiene una idea de por qué es eso y cómo resolverlo? No quiero agregar supresiones, porque esto ensuciaría seriamente el archivo GlobalSuppressions ya que hay bastantes ocurrencias.

Editado para agregar: Por el momento, he resuelto esto usando GlobalSuppressions, pero dada la naturaleza del problema, esta no parece ser la forma ideal de resolver esto. ¿Alguien puede dar una pista sobre dónde buscar más información sobre cómo FxCop aplica las reglas definidas en un diccionario?


32
2018-01-05 15:00


origen


Respuestas:


Desarrollé FxCop / Managed Code Analysis Team durante 3 años y tengo su respuesta. Las cosas han cambiado desde mi época, y había olvidado exactamente cómo funcionaba el manejo de diccionarios personalizados, así que me tomó bastante tiempo resolver esto. :)

Resumen ejecutivo

La respuesta breve es que debe eliminar todas las referencias a nombre de usuario, nombres de usuario, nombre de usuario y nombres de usuario de C: \ Archivos de programa (x86) \ Microsoft FxCop 1.36 \ CustomDictionary.xml.

Normalmente, no recomendaría esto, ya que no debería ser necesario, pero ha encontrado lo que creo que es un error, y esta es la única solución que pude encontrar.

Historia completa

OK, ahora para el largo responder...

La regla tiene dos controles distintos que funcionan de la siguiente manera:

A. Compruebe si hay palabras compuestas que deberían ser discretas

  1. Dividir identificador en tokens: p. Ej. FileName --> { "file", "name" }
  2. Revise con ortografía cada par de tokens adyacentes.
  3. Si la revisión ortográfica tiene éxito (p. filename se considera que es una palabra válida),
     entonces hemos encontrado un problema potencial ya que una sola palabra no debe expresarse como  dos tokens
  4. Sin embargo, si hay un <Term CompoundAlternate="FileName">filename</Term>   en el <Compound> sección del diccionario personalizado, entonces se toma como que significa  a pesar de que filename es una palabra, las pautas de diseño (en gran parte como un guiño a la coherencia)  con el estado de la técnica en el Marco que es anterior a la existencia de la regla) insista  debe escribirse como FileName, y entonces debemos suprimir la advertencia.
  5. Además, si hay un <Term>filename</Term> entrada en el <DiscreteExceptions>   sección del diccionario personalizado, entonces se entiende que aunque 'nombre de archivo'  una palabra, también podría ser dos palabras 'archivo' y 'nombre' en un contexto diferente. p.ej.  Onset es una palabra, pero le pide al usuario que cambie DoSomethingOnSet a   DoSomethingOnset sería ruido, y entonces debemos suprimir la advertencia.

B. Busque palabras discretas que deberían ser compuestas:

  1. Tomando los tokens de A.1, comprueba cada uno individualmente contra el conjunto de compuesto  términos en el diccionario personalizado.
  2. Si hay una coincidencia, entonces debemos advertir de acuerdo con la interpretación en el paso A.4.

Tenga en cuenta que su advertencia: Username debiera ser UserName se detecta en la parte B, que no consulta la sección DiscreteExceptions, por lo que no puede suprimir la advertencia modificando esa sección. El problema es que el diccionario personalizado predeterminado tiene una entrada que indica que la carcasa correcta para username es siempre UserName. Necesita ser eliminado o anulado de alguna manera.

El bicho

Ahora, la solución ideal sería dejar solo el diccionario personalizado predeterminado, especificar SearchFxCopDir=false en su archivo de proyecto, y luego combine solo las partes del diccionario personalizado predeterminado que desea en el CustomDictionary.xml que se utiliza para su proyecto. Lamentablemente, esto no funciona, ya que FxCop 1.36 ignora la directiva SearchFxCopDir y siempre la trata como verdadera. Creo que esto es un error, pero también es posible que esto haya sido un cambio intencional ya que la directiva no está documentada y no tiene una IU correspondiente. Honestamente, no sé ...

Conclusión

Dado que FxCop siempre utiliza su diccionario personalizado predeterminado además del diccionario personalizado del proyecto, su único recurso es eliminar las entradas en cuestión del diccionario personalizado predeterminado.

Si tengo la oportunidad, me pondré en contacto con el equipo de análisis de código actual para ver si esto es un error, e informaré aquí ...


31
2018-01-12 07:27



En el diccionario personalizado que viene con FxCop (ubicado en mi sistema en C: \ Archivos de programa \ Microsoft FxCop 1.36 \ CustomDixtionary.xml, pero YMMV) en Words \ Compounds tiene un <Term CompoundAlternate="UserName">username</Term> entrada. Bórralo. Aún necesitas la excepción discreta.


3
2018-01-12 06:24