¿Están recomendados los estándares de codificación .NET / C #? [cerrado]

19

¿Qué estándares de codificación crees que son importantes para los proyectos .NET / C #? Esto podría ser cualquier cosa, desde lidiar con llaves y espacios y pedales como ese. O podrían ser preguntas más fundamentales, como qué espacios de nombres en .NET Framework evitar, las mejores prácticas con archivos de configuración, etc.

Intenta evitar crear una publicación que sea simplemente el corolario de otra. Por ejemplo, estaría bien tener una publicación centrada en llaves. No necesitamos dos para admitir un estilo frente al otro. La idea no es votar por el estándar de su mascota, sino desarrollar lo que se debe pensar al crear estándares.

RationalGeek
fuente

Respuestas:

29

Aquí está la Guía oficial de Microsoft sobre estándares de codificación para .NET Framework Versión 4.0.

Si desea la versión anterior para 1.1, intente aquí .

No necesariamente sigo esto a una 'T', como dicen. Sin embargo, en caso de duda, este es el mejor lugar para comenzar a ser coherente con el marco .NET actual, lo que lo hace más fácil para todos, sin importar si son nuevos en su proyecto particular o no.

Ryan Hayes
fuente
3
Sí, no puede equivocarse haciendo coincidir lo que usan las personas que crean el software. He visto algunas guerras religiosas sobre este tipo de cosas, pero cuando te entregan algo que permitirá que tu propio código sea coherente con los marcos que está utilizando, tendrás que tener un argumento extremadamente fuerte para no usarlo. Como beneficio adicional, las herramientas de análisis estático que MS produce ya están ajustadas para buscar estas prácticas.
Todd Williamson
¿Puedo obtener algún comentario sobre el voto negativo, por favor?
Ryan Hayes
¿Qué no sigues?
JeffO
Bueno, hay muchas cosas allí y todavía no las he memorizado. Entonces, en lugar de decir que lo sigo exactamente (lo cual no sé si hago, por lo que puede o no ser cierto), solo digo que no, jaja. Si supiera todo esto probablemente lo sabría.
Ryan Hayes
10

Quizás quieras echar un vistazo a StyleCop . Incluso puede incorporarlo en algunos sistemas de compilación para que los errores de estilo rompan la compilación. La configuración predeterminada es en su mayoría congruente con lo que MS sugiere para las pautas (según lo publicado por otros).

También puede modificar las reglas que vienen con el valor predeterminado.

Steven Evers
fuente
4

Comience con FxCop . Le informará sobre las infracciones de mejores prácticas en su código existente.

Victor Hurdugaci
fuente
FxCop analiza los archivos binarios, no le informará sobre el estilo de codificación, pero detectará algunos problemas.
Steve
2

Tengo que recomendar los estándares puestos a disposición por SSW (una empresa de consultoría australiana).

No solo codificación, sino gestión de proyectos, etc. Un recurso increíblemente valioso.

http://www.ssw.com.au/ssw/standards/default.aspx

davewasthere
fuente
2

Los métodos deben ser cortos.

La mayoría de los métodos deberían usar la mayoría de los campos en una clase.

Elige bien tus nombres.

Por ejemplo, lea el libro Clean Code

Ian
fuente
2

Estoy usando las siguientes aplicaciones para mantener un estándar de codificación además de las reglas de camello, el nombre del método, etc.

GhostDoc : agrega un comentario generado automáticamente en la parte superior de cada método. La aplicación proporciona un buen resumen inicial del método. (gratis)

http://submain.com/products/ghostdoc.aspx

Resharper - análisis de código y refactorización http://www.jetbrains.com/resharper/

StyleCop : como limpieza final antes de registrarme en TFS. (gratis)

http://code.msdn.microsoft.com/sourceanalysis

Nickz
fuente
1

Odio los estándares de codificación establecidos, a todos les preocupa decirte que no cometas algunos errores tontos o decirte cómo formatear tu código de una forma u otra. Todo lo cual son trivialidades.

Quiero decir, le dirán cuántos espacios colocar entre operadores, cómo colocar sus variables en caso, qué prefijos de 'estilo húngaro' usar (por ejemplo, _ para miembros), consejos contradictorios (por ejemplo, no puede llamar a una clase Cxyz pero debe llame a una interfaz Ixyz), cómo diseñar su código (coloque su variable en la parte superior de la clase o en la parte inferior)

Todos son inútiles en el panorama general.

Lo que importa para escribir código efectivo, fácil de mantener y legible nunca se menciona en estos estándares.

Por ejemplo: ¿coloca sus variables en la parte superior o inferior de su clase? Bueno, a quién le importa; lo que importa es si agrupa sus variables por área funcional. Eso es importante (lo sabrás si alguna vez has visto 20 variables dispersas por el lugar).

Te dicen que pongas tus llaves en ciertos lugares. ¡Vaya cosa! Puedo leer el código en los corchetes de estilo K&R y ANSI, no importa. Lo que importa es si todas las clases de Windows se diferencian de alguna manera (como el sufijo con Form o Dlg o lo que sea) para que pueda ver qué archivos contienen código de ventana y cuáles son objetos comunes.

Cosas como esta son mucho más importantes que los puntos menores que suelen contener los estándares. No sé por qué se desarrollaron así, pero a menudo son solo un montón de reglas que se interponen en el camino de una codificación efectiva y productiva.

Mis estándares intentan centrarse más en la organización del código y los archivos. Tenemos ciertos estándares que se refieren a dónde se encontrarán los archivos. Por ejemplo, los no desarrolladores pueden ver uno de nuestros proyectos e inmediatamente recoger los archivos de documentación que necesitan. Del mismo modo, tratamos de diseñar el código del proyecto de una manera tan similar a otros proyectos como sea práctico (nota: como práctico, no de una manera muy proscrita que puede no ser apropiada todo el tiempo) y, básicamente, tratamos de establecer pautas estándar que Se puede modificar según sea necesario.

En pocas palabras - que están ahí para ayudarnos a trabajar juntos, no como un conjunto de reglas restrictivas que siempre tienen que ser seguidos.

gbjbaanb
fuente
1

Advertencia: pragmatismo a continuación : la pregunta parece estar redactada para provocar un debate sobre el estilo "apropiado" de llaves, etc. No soporto perder el tiempo en esas tonterías.

  1. Instale ReSharper , deje los valores predeterminados, haga lo que diga.

  2. Beneficio: todos en su equipo tendrán el mismo estilo que estará muy cerca de las pautas de Microsoft, solo se desviarán en unos pocos puntos en los que los estándares de Resharper reflejan lo que en realidad se usa más ampliamente en la industria y son (posiblemente) mejoras.

Cuanto menos tiempo pase su equipo creando y haciendo referencia a algún documento o libro gigantesco, o dándole vueltas sobre las curly bracesy otras tonterías, más codificación harán. ReSharper impondrá los nombres y el estilo a medida que escriben. Hecho. Fin del debate. No queda nada por qué discutir. Hacia adelante.

Dicho esto, una lectura del clásico Código Completo , los ayudará a comprender la lógica detrás de los estándares de codificación, y ofrecerá muchos buenos consejos para transmitir el significado de manera efectiva a través del código, algo que un documento de estándares o un programa de inspección no puede hacer.

Si desea intensificar lo que resharper puede hacer por usted, agregue StyleCop con el complemento StyleCop for ReSharper. Como se mencionó, habrá algunos conflictos menores entre las pautas de MS y los valores predeterminados de ReSharper. Simplemente iría con ReSharper en esos. Pero cualquiera que sea el lado que tome, simplemente guarde los resultados en el archivo de configuración de ReSharper, compártalos con su equipo y listo.

(No, no soy un shill pagado para ReSharper, solo un cliente satisfecho. Además de sus muchas otras características, maneja los problemas de estilo básicos de manera más rentable que cualquier documento estándar o sistema de revisión de código, dejando la capacidad intelectual para las cosas que importan .)

DanO
fuente