¿Cuáles son las reglas de FxCop "deben seguir" para cualquier desarrollador de C#?

Question

Estoy planeando comenzar a utilizar FxCop en uno de nuestros proyectos en curso. Pero, cuando lo probé con la selección de todas las reglas disponibles, parece que tengo que hacer muchos cambios en mi código. Siendo un "miembro del equipo" no puedo empezar a hacer estos cambios, como nombrar cambio de convención, etc. de todos modos me gustaría comenzar a usar FxCop con un conjunto mínimo de reglas y aumentar gradualmente el conjunto de reglas a medida que avanzamos. ¿Puede sugerirme que algunos deben tener reglas de FxCop que debería comenzar a seguir? ¿O sugieres algún mejor enfoque?

Nota: La mayor parte de mi código está en C#.

Answer 1

Las reglas de diseño y seguridad son un buen lugar para comenzar.

Answer 2

En mi opinión, haga lo siguiente:

Para cualquier nuevo proyecto, siga todas las reglas de FxCop. Es posible que desee desactivar algunos de ellos, ya que no todo tendrá sentido para su proyecto. Para un proyecto existente, siga las reglas de estas categorías como un conjunto mínimo:

• globalización
• Interoperabilidad
• Seguridad
• Rendimiento
• Portabilidad

Dado que estos son típicamente solo algunas infracciones a las reglas en un proyecto existente, en comparación con las otras categorías, pero pueden mejorar la calidad de su aplicación. Cuando estas reglas son claras, tratar de arreglar las siguientes categorías:

• Diseño
• Uso

Desde estos hará que sea más fácil para usted para detectar errores que tienen que ver con las violaciónes, pero tendrá una gran cantidad de violaciones en el código existente.

Siempre clasifique las violaciones por nivel/categoría de corrección y comience por las críticas. Omita las advertencias por ahora.

En caso de que no lo sepa, también hay disponible StyleCop de Microsoft, verificando su código en el nivel de la fuente. Asegúrese de habilitar la integración de MSBuild durante la instalación.

Answer 3

En nuestro código más importante:

• advertencias tratan como errores (nivel 4)
• FxCop debe pasar 100% (no ignora generalmente permitidos)
• Gendarme utilizarse como una guía (a veces entra en conflicto con FxCop)

Lo creas o no, FxCop te enseña muchísimo sobre cómo escribir mejor código ... ¡una gran herramienta! Entonces, para nosotros, todas las reglas son igualmente importantes.

Answer 4

Somos una tienda on-line para que deje caer las siguientes reglas:

• Cualquier cosa con interoperabilidad (no apoyamos la integración COM a menos que un cliente paga por ello!)
• clave de firma (aplicaciones web no debería ser necesario prilages de alta seguridad)

occationally vamos a dejar la regla sobre el uso de los marcos superiores en dependencias como algunos de nuestros de CMS son todavía .NET 2.0, pero eso no significa que las capas DAL/negocio puede no sea .NET 3.5 siempre y cuando no intente devolver un IQueryable (o un nada .NET 3, 3.5).

Answer 5

Estoy totalmente de acuerdo con Sklivvz. Pero para proyectos existentes, puede limpiar la categoría de violaciones de FxCop por categoría.

De vez en cuando, Gendarme acepta nuevas reglas que son bastante útiles. Entonces puedes usar Gendarme además.

Answer 6

En nuestro proceso, habilitamos todas las reglas y luego tenemos que justificar las supresiones como parte de nuestro proceso de revisión. A menudo, simplemente no es posible corregir el error de forma eficiente en el tiempo con respecto a las fechas límites o si se produce un error por error (esto ocurre a veces, especialmente si su arquitectura maneja los complementos a través de la reflexión).

También escribimos una regla personalizada para la globalización para reemplazar una existente porque no queríamos globalizar las cadenas pasadas a las excepciones.

En general, diría que es mejor intentar y cumplir con todas las reglas. En mi proyecto actual, tengo cuatro configuraciones de compilación, un conjunto que especifica la definición CODE_ANALYSIS y un conjunto que no. De esta forma, puedo ver todos los mensajes que he suprimido simplemente construyendo una configuración que no sea CODE_ANALYSIS. Esto significa que los mensajes suprimidos pueden revisarse periódicamente y potencialmente abordarse o eliminarse según sea necesario.

Lo que me gustaría hacer a largo plazo es tener un paso de compilación que analice los atributos de SuppressMessage contra los errores reales y destaque las supresiones que ya no son necesarias, pero que actualmente no es posible con mi configuración.

Answer 7

Una alternativa a FxCop sería utilizar la herramienta NDepender que permite escribir Code Rules over C# LINQ Queries (namely CQLinq). Descargo de responsabilidad: soy uno de los desarrolladores de la herramienta

Más de 200 code rules se han propuesto por defecto. La personalización de las reglas existentes o la creación de sus propias reglas es sencilla gracias a la conocida sintaxis C# LINQ.

NDepender las superposiciones con FxCop en algunas reglas de código, pero propone muchas reglas de código únicas.Aquí hay algunas reglas que yo clasificaría como debe seguir:

• Avoid decreasing code coverage by tests of types
• Avoid making complex methods even more complex (Source CC)
• Avoid transforming an immutable type into a mutable one
• Overrides of Method() should call base.Method()
• Avoid the Singleton pattern
• Types with disposable instance fields must be disposable
• Disposable types with unmanaged resources should declare finalizer
• Avoid namespaces mutually dependent
• Avoid namespaces dependency cycles
• UI layer shouldn't use directly DB types
• API Breaking Changes: Methods
• Complex methods partially covered by tests should be 100% covered
• Potentially dead Types
• Structures should be immutable
• Avoid naming types and namespaces with the same identifier

Observe que las Reglas se pueden verificar live in Visual Studio y en Tiempo de proceso de compilación, en un generated HTML+javascript report.

Answer 8

Encienda una regla a la vez. Arregle o excluya las advertencias que informa, luego comience con la siguiente.

Answer 9

Algunas de las reglas nos evitan errores o derrames:

• no debe quedar atrapado tipos de excepciones generales (puede ser la mejor regla para nosotros Según el caso, puede ser fácil o difícil de hacer cumplir.)
• prueba para NaN correctamente (fácil de hacer cumplir)
• campos desechables deben ser eliminados (bastante fácil de hacer cumplir)
• Desechar debe llamar a disponer de base (bastante fácil de hacer cumplir)
• tipos desechables deben declar e finalizador (bastante fácil de aplicar)

Algunos nos ayudan a tener un mejor diseño, pero tenga cuidado, pueden llevarlo a una refactorización grande cuando la API central se ve afectada. Nos gusta

• propiedades de recolección deben ser de sólo lectura (difíciles de aplicar en nuestro caso)
• No exponga lista genérica
• miembro no debe exponer a ciertos tipos conrete
• Revisión usuned parámetros (Mejora fácilmente su API)

Alguien en nuestro proyecto probó las reglas de rendimiento sin ninguna mejora. (En realidad, estas reglas son sobre micro-optimización, lo que no da ningún resultado si ninguna identificación de cuello de botella muestra que se necesita micro-optimización). Sugeriría no comenzando con estos.

Answer 10

El FxCop mínima y también análisis de código (si se utiliza VS2010 Premium o Ultimate) es la siguiente: http://msdn.microsoft.com/en-us/library/dd264893.aspx