¿Hay alguna sugerencia para desarrollar un documento de estándares / mejores prácticas de codificación C #? [cerrado]

Soy un recién graduado de IA (alrededor de 2 años) que trabaja para una operación modesta. Se me ha ocurrido a mí (principalmente porque soy el primer 'adoptante' en el departamento) crear un documento básico de estándares de codificación C # (¿lees útil?).

Creo que debería explicar que probablemente soy el ingeniero de software más joven, pero estoy ansioso por esta tarea, ya que espero poder producir algo medio utilizable. Hice una búsqueda bastante extensa en Internet y leí artículos sobre lo que un documento de estándares de codificación debería / no debería contener. Este parece ser un buen lugar para pedir algunas sugerencias.

Me doy cuenta de que potencialmente estoy abriendo una puerta a todo un mundo de desacuerdo sobre "la mejor manera de hacer las cosas". 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 nada tan draconianamente proscriptivo como para sofocar el talento personal, sino para tratar de obtener una metodología general y acordado estándares (por ejemplo, convenciones de nomenclatura) para ayudar a que los códigos individuales sean más legibles.

Así que aquí va ... alguna sugerencia? ¿Algo en absoluto?

Empezamos con

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

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

IDesign tiene un documento de estándares de codificación C # que se usa comúnmente. Consulte también las Directrices de diseño de marcos de la 2ª ed .

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

Mi primera sugerencia sería obtener sugerencias de los otros ingenieros sobre lo que consideran que debería cubrirse, y las pautas que consideran importantes. Hacer cumplir cualquier tipo de pautas requiere un cierto grado de aceptación por parte de las personas. Si de repente sueltas un documento que especifica cómo escribir código, encontrarás resistencia, ya sea que seas el chico más joven o mayor.

Una vez que tenga un conjunto de propuestas, envíelas al equipo para recibir comentarios y revisión. Nuevamente, haga que todas las personas los compren.

Es posible que ya se hayan adoptado prácticas de codificación informales (por ejemplo, prefijar variables de miembros, nombres de funciones de camello). Si esto existe, y la mayoría del código se ajusta a él, entonces pagará formalizar su uso. Adoptar un estándar contrario causará más dolor del que vale, incluso si es algo generalmente recomendado.

También vale la pena considerar refactorizar el 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ás una mezcla 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.

Siempre he usado el pdf de Juval Lowy como referencia al hacer 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, debería ser capaz de llegar a un buen estándar que a todos sus desarrolladores no les importe seguir y poder aplicar.

Los otros carteles lo han señalado en la línea de base, todo lo que agregaría es hacer que su documento sea corto, dulce y al punto, empleando una fuerte dosis de Strunk y White para distinguir los "must haves" del "sería bueno si ".

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 dicho documento sea leído y seguido varía inversamente con su extensión.

Estoy de acuerdo en que FxCop es una buena herramienta, pero demasiado de esto puede sacar toda la diversión de la programación, así que tenga cuidado.

Nunca escriba sus propios estándares de codificación, use los de MS (o los de Sun o ... según corresponda para su idioma). La clave está en la palabra estándar, el mundo sería un lugar mucho más fácil de codificar si cada organización no hubiera decidido escribir la suya. Quien 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 debería hacer es resumir los puntos críticos, pero le aconsejaría que no lo hiciera, ya que lo crítico varía de persona a persona. Otros dos puntos que me gustaría destacar sobre los estándares de codificación

1. Cerrar es lo suficientemente bueno: cambiar el código para seguir los estándares de codificación al pie de la letra es una pérdida de tiempo siempre que 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 circundante.

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

La siguiente documentación me pareció muy útil y concisa. Proviene del sitio idesign.net y está escrito por Juval Lowy

Estándar de codificación C #

NB: el enlace anterior ahora está muerto. Para obtener el archivo .zip, debe proporcionarles su dirección de correo electrónico (pero no lo usarán para marketing ... honestamente) Inténtelo aquí

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. Entonces, podría tener algo como esto en el cuerpo de un método:

m_strName = p_strName;

Horrible. Realmente horrible

Agregaría Code Complete 2 a la lista (sé que Jeff es un fanático aquí) ... Si usted es un desarrollador junior, el libro es útil para configurar su mente de una manera que sienta las bases para lo mejor prácticas de escritura de código y construcción de software que hay.

Tengo que decir que llegué un poco tarde en mi carrera, pero determina muchas de las formas en que pienso sobre la codificación y el desarrollo de marcos en mi vida profesional.

Vale la pena echarle un vistazo;)

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

Me sentiría tentado a aplicar StyleCop de Microsoft como estándar. Se puede aplicar en el momento de la construcción. pero si tiene código heredado, simplemente aplique StyleCop en el nuevo código.

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

Eventualmente tendrá una opción de refactorización para limpiar el código.

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

Personalmente, me gusta el que IDesign ha creado. Pero no es por eso que estoy publicando ...

La parte difícil de mi empresa fue tener en cuenta todos los idiomas diferentes. Y sé que mi compañía no está sola en esto. Usamos C #, C, ensamblaje (creamos 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 nivel superior tienen un mayor impacto en la calidad del producto final. Por ejemplo: cómo y cuándo usar comentarios, cuando 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é debe ser el código del controlador versus el código de presentación, etc. No me malinterpreten, también se necesitan estándares de bajo nivel (¡el formato es importante para la legibilidad!) Simplemente tengo un sesgo hacia la estructura general.

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

Mientras escribía tanto el publicado para Philips Medical Systems como el publicado en http://csharpguidelines.codeplex.com , podría estar un poco sesgado, pero tengo más de 10 años escribiendo, manteniendo y promoviendo estándares de codificación. Intenté escribir el CodePlex con las diferencias de opiniones en mente y pasé la mayor parte de la introducción sobre cómo lidiar con eso en su organización en particular. Léelo y dame tu opinión .....

Reglas de SSW

Incluye algunos estándares de C # + mucho más ... enfocado principalmente en desarrolladores de Microsoft

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

No estoy de acuerdo, siempre que él cree el documento, lo peor que puede pasar es que todos lo olviden.

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

Recientemente encontré el Manual de Encodo C # , que incluye ideas de muchas otras fuentes (IDesign, Philips, MSDN).

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

Soy un gran admirador del libro de Francesco Balena " Directrices prácticas y mejores prácticas para desarrolladores de VB y C # ".

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

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

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

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

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

Puede consultar esto, los 7 principales estándares de codificación y documentos de guía para desarrolladores de C # / .NET http://www.amazedsaint.com/2010/11/top-6-coding-standards-guideline.html espero que esto ayude

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

Lo cual es interesante porque mi gerente me ha dicho en el pasado que no está muy interesado en ellos: D

Tienes una tarea divertida por delante, amigo mío. Mucha suerte, y por favor pregunte si necesita algo más :)

El estándar de Philips Medical Systems está bien escrito y sigue principalmente las pautas 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 está un poco anticuado).

También sigo a 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

En el código que escribo, generalmente sigo las Pautas de diseño de .NET Framework para API expuestas públicamente y las Pautas de codificación mono para la carcasa y sangría de miembros privados . Mono es una implementación de código abierto de .NET, y creo que esos tipos conocen su negocio.

Odio cómo el código de Microsoft desperdicia 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 resultar extraño en las pautas de Mono es que usan pestañas 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 una especie 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 imponga nada de eso si a sus compañeros de trabajo no les gusta (a menos que esté dispuesto a contribuir a Mono ;-)