visual studio .net visual-studio code-analysis stylecop

.net - studio - stylecop rules



¿Alternativa a StyleCop para Visual Studio? (7)

Me gusta el análisis de código estático y la aplicación de reglas de StyleCop . Sin embargo, falta mucho en varios departamentos clave.

  • Agregar nuevas reglas no es oficialmente compatible y por lo que escucho es bastante difícil.
  • ¡La "fijación" automática de violaciones de reglas triviales sería agradable! Tal vez no con nombres variables, pero con el orden de los métodos (estáticos, etc.) esto sería un gran ahorro de tiempo.
  • El enfoque de Microsoft de "talla única" de Microsoft es algo restrictivo. Me gustaría tener un conjunto personalizado de reglas para nuestros estándares internos.

¿Hay tal producto comercial por ahí?

alt text http://blogs.interakting.co.uk/images/blogs_interakting_co_uk/dominicz/WindowsLiveWriter/MicrosoftStyleCopSourcecodeanalysisforfo_D8EF/styleCopErrors_6.gif



Hay Gendarme de Mono, aunque es de código abierto, no comercial.


Agregar reglas es, o va a ser, oficialmente compatible :

Tal como prometimos, también lanzaremos documentación de SDK para StyleCop explicando cómo crear reglas personalizadas y cómo integrar la herramienta en entornos de construcción personalizados. La documentación del SDK se encuentra actualmente en revisión final y esperamos lanzarla muy pronto. - JasonAll

En términos de nuestro estilo "interno", me acerqué bastante al desactivar un puñado de reglas de StyleCop:

  • Cabeceras de archivo (SA1633-SA-1640)
  • Código ordenado (SA1200-SA1202)
  • Requerir "esto" (SA1101)

Puede hacerlo globalmente modificando el archivo Settings.StyleCop en el directorio de instalación, aunque he tomado el enfoque de poner uno en la raíz de nuestro árbol fuente en cada proyecto.

El efecto final es mucho lo que queremos. Hay un puñado de opciones "internas" que sería bueno marcar, pero incluso sin ellas, StyleCop nos está brindando un gran valor.


StyleCop for ReSharper podría ser útil (necesitaría comprar ReSharper, pero el complemento es gratuito):

StyleCop for ReSharper ahora es una característica completa que ha alcanzado la paridad de características con StyleCop 4.3.

Hay 148 reglas de StyleCop.

  • 38 de ellos se deben arreglar manualmente (normalmente porque tiene que escribir texto descriptivo o cambiar el nombre de las variables).
  • De las 110 reglas restantes, 58 están corregidas por R # Code Cleanup (modo silencioso).
  • De los 52 que quedan ahora, tenemos reglas de limpieza del código que los arreglan a todos automáticamente.

También proporcionamos 106 soluciones rápidas que proporcionan correcciones del menú contextual en caso de violaciones de las 110 reglas que se pueden corregir automáticamente.

También enviamos un "archivo de configuración de uso compartido de estilo ReSharper Code Friendly" de StyleCop que configura ReSharper para formatear automáticamente el código de una manera amigable con StyleCop.


Una alternativa o un buen complemento para StyleCop sería usar la herramienta comercial NDepend . Con esta herramienta, uno puede escribir Code Rule sobre LINQ Queries (es decir, CQLinq) . Descargo de responsabilidad: soy uno de los desarrolladores de la herramienta

Se proponen por defecto más de 200 reglas de código , que incluyen diseño , arquitectura , calidad de código , evolución de código , convenciones de nomenclatura , código muerto , uso de .NET Fx ...

CQLinq está dedicado a escribir reglas de código que pueden verificarse en vivo en Visual Studio , o que pueden verificarse durante el proceso de compilación e informarse en un informe HTML / javascript .

La fuerza de CQLinq sobre StyleCop o incluso FxCop, es que es sencillo escribir una regla de código y obtener resultados inmediatos . Se proponen instalaciones para buscar elementos de código coincidentes. Concretamente, esto se ve así:



A menudo escribo pruebas unitarias para reflexionar sobre mis tipos y verificar violaciones de mis reglas personalizadas.

Aquí hay un ejemplo para verificar que ciertos tipos son inmutables: http://blogs.msdn.com/kevinpilchbisson/archive/2007/11/20/enforcing-immutability-in-code.aspx

Aquí hay otra, para las reglas sobre el nombre de la prueba unitaria: http://jbazuzicode.blogspot.com/2008/11/ keeping- test-fixture- and - class - names.html

EDITAR: El segundo enlace parece estar perdido en las arenas del tiempo.