¿Hay alguna sugerencia para desarrollar un documento de normas/mejores prácticas de codificación de C#?

Question

Soy un recién graduado de AI (alrededor de 2 años) trabajando para una operación modesta. Me ha tocado a mí (principalmente porque soy el primer 'adoptador' en el departamento) crear un documento de estándares de codificación C# básico (¿es útil leerlo?).

Creo que debería explicar que probablemente soy el ingeniero de software más joven en activo, pero estoy deseando que llegue esta tarea, ya que con suerte podría ser capaz de producir algo a medias. Realicé una búsqueda bastante extensa de Internet y leí artículos sobre lo que un documento de estándares de codificación debería/no debería contener. Esto parece un lugar tan bueno como cualquiera para pedir algunas sugerencias.

Me doy cuenta de que potencialmente estoy abriendo la puerta a un mundo de desacuerdos sobre 'la mejor manera de hacer las cosas'. Yo entiendo y respeto el hecho innegable de que cada programador tiene un método preferido para resolver cada tarea individual, como resultado, no estoy buscando escribir algo tan draconianamente proscriptivo como para sofocar el talento personal, sino para intentar obtener una metodología general y acordar estándares (por ejemplo, convenciones de nomenclatura) para ayudar a que los códigos de los individuos sean más legibles.

Así que aquí va .... alguna sugerencia? Cualquiera en absoluto?

Answer 1

empezamos con

• las directrices de Microsoft .NET: http://msdn.microsoft.com/en-us/library/ms229042.aspx (enlace actualizados para .NET 4.5)
• de Microsoft C# guidelines: http://blogs.msdn.com/brada/articles/361363.aspx.

y luego documentar las diferencias y las adiciones a esa línea base.

Answer 2

Las propias reglas de Microsoft son un excelente punto de partida. Puede aplicarlos con FxCop.

Answer 3

Siempre he usado el pdf de Juval Lowy como referencia al hacer las normas de codificación/mejores prácticas internamente. Sigue muy cerca de FxCop/Source Analysis, que es otra herramienta invaluable para asegurarse de que se siga el estándar. Entre estas herramientas y referencias, debe poder encontrar un buen estándar que a todos sus desarrolladores no les importe seguir y poder hacer cumplir.

Answer 4

IDesign tiene un documento de estándares de codificación C# que se utiliza comúnmente. También vea el Framework Design Guidelines 2nd Ed.

Answer 5

Los otros carteles lo han señalado en la línea de base, todo lo que yo agregaría es hacer que su documento sea breve, dulce y al grano, empleando una gran dosis de Strunk y White para distinguir los "imprescindibles" del " Sería bueno ifs ".

El problema con los documentos de estándares de codificación es que nadie los lee realmente como deberían, y cuando los leen, no los siguen. La probabilidad de que se lea y se lea un documento de este tipo varía de forma inversa a su longitud.

Acepto que FxCop es una buena herramienta, pero una gran parte de esto puede quitar toda la diversión de la programación, así que ten cuidado.

Answer 6

Irónicamente, establecer los estándares reales es la parte fácil.

Mi primera sugerencia sería obtener sugerencias de los otros ingenieros sobre lo que ellos sienten que debería ser cubierto, y qué pautas sienten que son importantes.La aplicación de cualquier tipo de directrices requiere un grado de aceptación por parte de las personas. Si de repente deja caer un documento sobre ellos que especifica cómo escribir el código, encontrará resistencia, ya sea que sea el tipo más joven o mayor.

Después de recibir un conjunto de propuestas, envíelos al equipo para comentarios y evaluaciones. Nuevamente, haga que la gente compre en ellos.

Es posible que ya existan prácticas de codificación informales que se adopten (p. Ej., Prefijar variables de miembros, nombres de funciones de camelcase). Si esto existe, y la mayoría de los códigos se ajustan a él, pagará formalizar su uso. Adoptar un estándar contrario va a causar más pena de lo que vale, incluso si es algo generalmente recomendado.

También vale la pena considerar la refacturación del código existente para cumplir con los nuevos estándares de codificación. Esto puede parecer una pérdida de tiempo, pero tener un código que no cumpla con los estándares puede ser contraproducente ya que tendrá una mezcolanza de diferentes estilos. También deja a las personas en un dilema si el código en un determinado módulo debe ajustarse al nuevo estándar o seguir el estilo de código existente.

Answer 7

Creo que me hago eco de los otros comentarios aquí que los guidlines MS ya vinculados son un excelente punto de partida. Modelo mi código en gran medida en esos.

cual es interesante porque mi jefe me ha dicho en el pasado que no está demasiado interesado en ellas: D

tiene una tarea divertida delante de usted mi amigo. La mejor de las suertes, y pregunte si necesita algo más :)

Answer 8

Lo más probable es que esté configurado para fallar. Bienvenido a la industria.

No estoy de acuerdo - siempre y cuando cree el documento, lo peor que puede pasar es que lo olvide todo el mundo.

Si otras personas tienen problemas con el contenido, puede pedirles que lo actualicen para mostrar lo que prefieren. De esta forma, está fuera de tu control, y los demás tienen la responsabilidad de justificar sus cambios.

Answer 9

Nunca escriba sus propios estándares de codificación utilizando los de MS (o los de Sun o ... según corresponda para su idioma). La clave está en el estándar de la palabra, el mundo sería un lugar mucho más fácil para codificar si cada organización no hubiera decidido escribir el suyo propio. ¿Quién realmente piensa que aprender un nuevo conjunto de 'estándares' cada vez que cambia equipos/proyectos/roles es un buen uso del tiempo de cualquier persona. Lo máximo que debe hacer es resumir los puntos críticos, pero le aconsejo que no lo haga porque lo que es crítico varía de persona a persona. Otros dos puntos que me gustaría hacer en los estándares de codificación

1. Close es lo suficientemente bueno - Cambio de código para seguir las normas de codificación de la carta es una pérdida de tiempo, siempre y cuando el código está lo suficientemente cerca.
2. Si está cambiando el código que no escribió, siga los 'estándares de codificación locales', es decir, haga que su nuevo código se vea como el código que lo rodea.

Estos dos puntos son la realidad de mi deseo que todos escriban código que se vea igual.

Answer 10

El estándar de Philips Medical Systems está bien escrito, y en su mayoría sigue las directrices de Microsoft: www.tiobe.com/content/paperinfo/gemrcsharpcs.pdf

Mis estándares se basan en esto con algunos ajustes, y algunas actualizaciones para .NET 2.0 (el estándar de Philips está escrito para .NET 1.x por lo que es un poco anticuado).

Answer 11

Estaría tentado de hacer cumplir StyleCop de Microsoft como estándar. Se puede aplicar en el momento de compilación. pero si tiene un código heredado, simplemente haga cumplir el uso de StyleCop en el nuevo código.

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

Eventualmente tendrá una opción para refactorizar código de limpieza.

http://blogs.msdn.com/sourceanalysis/

Answer 12

me gustaría añadir a la lista Code Complete 2 (sé que Jeff es una especie de ventilador aquí) ... Si usted es un desarrollador Junior, el libro viene muy bien para configurar su mente de una manera eso establece las bases para las mejores prácticas de escritura de código y construcción de software que existen.

Tengo que decir que llegué a este punto un poco tarde en mi carrera, pero que rige muchas de las formas en que pienso sobre la codificación y el desarrollo del marco en mi vida profesional.

Vale la pena echarle un vistazo;)

Answer 13

he encontrado recientemente Encodo C# Handbook, que incluye las ideas de muchas otras fuentes (IDesign, Philips, MSDN).

Otra fuente puede ser Professional C#/VB .NET Coding Guidelines.

Answer 14

Encontré la siguiente documentación muy útil y concisa. Viene de la página idesign.net y está escrito por Juval Lowy

C# Coding Standard

Nota: el enlace anterior ahora está muerto. Para obtener el archivo .zip, debe darles su dirección de correo electrónico (pero no la usarán para comercializar ... honestamente) Pruebe here

Answer 15

Soy un gran admirador del libro de Francesco Balena "Practical Guidelines and Best Practices for VB and C# Developers".

Es muy detallado y cubre todos los temas esenciales, no solo le da la regla, sino que también explica la razón detrás de la regla, e incluso proporciona una antirregulación donde podría haber dos mejores prácticas opuestas. El único inconveniente es que fue escrito para desarrolladores de .NET 1.1.

Answer 16

Ver esto: http://www.noesispedia.com/post/2008/11/28/C-Coding-Guidelines-and-Best-Practices.aspx.

Answer 17

Acabo de comenzar en un lugar donde los estándares de codificación exigen el uso de m_ para variables miembro, p_ para parámetros y prefijos para tipos, como 'str' para cadenas. Por lo tanto, puede tener algo como esto en el cuerpo de un método:

m_strName = p_strName;

Horrible. Realmente horrible

Answer 18

Personalmente me gusta el que IDesign ha puesto juntos. Pero no es por eso que estoy publicando ...

El truco de mi empresa era tener en cuenta todos los idiomas diferentes. Y sé que mi compañía no está sola en esto. Usamos C#, C, ensamblaje (hacemos dispositivos), SQL, XAML, etc.Aunque habrá algunas similitudes en los estándares, cada uno generalmente se maneja de manera diferente.

Además, creo que los estándares de mayor nivel tienen un mayor impacto en la calidad del producto final. Por ejemplo: cómo y cuándo usar los comentarios, cuándo las excepciones son obligatorias (por ejemplo, eventos iniciados por el usuario), si (o cuándo) usar excepciones vs. valores de retorno, ¿cuál es la forma objetiva de determinar qué código debe ser controlador versus código de presentación? etc. No me malinterprete, también se necesitan estándares de bajo nivel (¡el formateo es importante para la legibilidad!) Solo tengo un sesgo hacia la estructura general.

Otra pieza a tener en cuenta es la aceptación y el cumplimiento. Los estándares de codificación son geniales. Pero si nadie está de acuerdo con ellos y (probablemente más importante) nadie los aplica, entonces todo es en vano.

Answer 19

Todo nuestro estándar de codificación lee aproximadamente, "Use StyleCop".

Answer 20

Tengo que sugerir el documento dotnetspider.com.
Es un documento excelente y detallado que es útil en cualquier lugar.

Answer 21

He usado Juval antes y eso es todo si no excesivo, pero soy perezoso y ahora solo me conformaré con la voluntad de Resharper.

Answer 22

También sigo Resharper. también la línea de guía mencionada en el blog de Scott Guthrie http://weblogs.asp.net/scottgu/archive/2007/10/08/october-8th-links-asp-net-asp-net-ajax-silverlight-and-net.aspx Y http://csharpguidelines.codeplex.com/releases/view/46280

Answer 23

En el código que escribir yo suelo seguir .NET Framework Design Guidelines para las API expuestas públicamente y Mono Coding Guidelines de carcasa miembro privado y la sangría. Mono es una implementación de código abierto de .NET, y creo que esos tipos conocen su negocio.

me gusta cómo Microsoft desechos código de espacio:

try 
{ 
    if (condition) 
    { 
     Something(new delegate 
     { 
      SomeCall(a, b); 
     }); 
    } 
    else 
    { 
     SomethingElse(); 
     Foobar(foo, bar); 
    } 
} 
catch (Exception ex) 
{ 
    Console.WriteLine("Okay, you got me"); 
} 

lo que puede encontrar en las guías extraña Mono, es que utilizan tabuladores de 8 espacios. Sin embargo, después de un poco de práctica, descubrí que en realidad me ayuda a escribir código menos enredado al imponer un tipo de límite de sangría.

También me encanta cómo ponen un espacio antes de abrir paréntesis.

try { 
     if (condition) { 
       Something (new delegate { 
         SomeCall (a, b); 
       }); 
     } else { 
       SomethingElse(); 
       Foobar (foo, bar); 
     } 
} catch (Exception ex) { 
     Console.WriteLine ("Okay, you got me"); 
} 

Pero por favor, no cumplir nada de eso si sus compañeros de trabajo no les gusta (a menos que esté dispuesto a contribuir a Mono ;-)

Answer 24

Se puede extraer de esto, 7 mejores estándares de codificación & Directriz documentos para C# /. NET Desarrolladores http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html espero que esto ayude

Answer 25

Como he escrito tanto el publicado por Philips Medical Systems y el de http://csharpguidelines.codeplex.com que podría ser un poco subjetivo, pero tengo más de 10 años en la escritura, maintaing y la promoción de estándares de codificación. Intenté escribir el único CodePlex con las diferencias de opinión en mente y pasé la mayoría de la introducción sobre cómo lidiar con eso en su organización particular. Leerlo y me proporcione información de retorno .....

Answer 26

SSW Rules

Incluye algunas normas C# + mucho más ....enfocado principalmente a los desarrolladores de Microsoft