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

https://stackoverflow.com/questions/14967

08-06-2019
|

Pregunta

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

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

Me doy cuenta de que potencialmente estoy abriendo una puerta a todo un mundo de desacuerdos 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 busco escribir nada tan draconianamente proscriptivo como para sofocar el estilo personal, sino tratar de obtener una metodología general y acordada. estándares (por ej.convenciones de nomenclatura) para ayudar a que el código individual sea más legible.

Así que ahí va....¿alguna sugerencia?¿Alguno en absoluto?

Solución

Empezamos con

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

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

Otros consejos

Yo diseño tiene un documento de estándares de codificación C# que se usa comúnmente.Vea también el Directrices de diseño del marco 2.ª edición.

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 creen que debería cubrirse y qué pautas consideran importantes.Hacer cumplir cualquier tipo de directrices requiere cierto grado de aceptación por parte de la gente.Si de repente les dejas caer un documento que especifica cómo escribir código, encontrarás resistencia, ya seas el más joven o el más veterano.

Una vez que tenga un conjunto de propuestas, envíelas al equipo para recibir comentarios y revisión.Nuevamente, haga que la gente los acepte.

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

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 la gente en el dilema de si el código de un determinado módulo debe ajustarse al nuevo estándar o seguir el estilo de código existente.

Siempre he usado Juval Lowy's. pdf como referencia al realizar estándares/mejores prácticas de codificación internamente.Sigue muy cerca de FxCop/Análisis de fuente, que es otra herramienta invaluable para garantizar que se cumpla el estándar.Entre estas herramientas y referencias, debería poder crear un buen estándar que a todos sus desarrolladores no les importe seguir y poder aplicarlo.

Los otros carteles le han señalado la línea de base, todo lo que agregaría es que su documento sea breve, conciso y directo, empleando una gran dosis de Strunk and White para distinguir los "imprescindibles" de los "sería bueno si". ".

El problema con los documentos de estándares de codificación es que nadie los lee como debería, y cuando los lee, no los sigue. La probabilidad de que un documento de este tipo 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 quitarle toda la diversión a la programación, así que tenga cuidado.

Nunca escriba sus propios estándares de codificación, utilice los de MS (o los de Sun o...según corresponda a su idioma).La clave está en la palabra estándar: 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 cambias de equipo/proyectos/roles es un buen uso del tiempo de cualquiera?Lo máximo que debería hacer es resumir los puntos críticos, pero desaconsejaría ni siquiera hacerlo porque lo que es crítico varía de persona a persona.Otros dos puntos que me gustaría destacar sobre los estándares de codificación

Cerrar es 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.
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 parezca al código circundante.

Estos dos puntos son la realidad de mi deseo de que todos escribieran código que tuviera el mismo aspecto.

La siguiente documentación me pareció muy útil y concisa.Proviene del sitio idesign.net y su autor es Juval Lowy.

Estándar de codificación C#

NÓTESE BIEN:el enlace de arriba ahora está muerto.Para obtener el archivo .zip, debes darles tu dirección de correo electrónico (pero no la usarán para marketing...honestamente) intenta 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, es posible que tengas algo como esto en el cuerpo de un método:

m_strName = p_strName;

Horrible.Realmente horrible.

yo podria agregar Código completo 2 a la lista (sé que Jeff es un fan aquí)...Si es un desarrollador junior, el libro resulta útil para configurar su mente de una manera que establezca las bases para las mejores prácticas de escritura de código y creación de software que existen.

Debo decir que llegué a esto un poco tarde en mi carrera, pero rige 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 hacerlas cumplir con FxCop.

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

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

Con el tiempo, tendrá una opción de refactorización para limpiar el código.

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

Personalmente me gusta el que Yo diseño ha reunido.Pero no es por eso que estoy publicando...

Lo complicado en mi empresa fue tener en cuenta todos los diferentes idiomas.Y sé que mi empresa no está sola en esto.Usamos C#, C, ensamblador (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 utilizar comentarios, cuándo las excepciones son obligatorias (p. ej.eventos iniciados por el usuario), si (o cuándo) usar excepciones vs.valores de retorno, cuál es la forma objetiva de determinar cuál debería ser el código del controlador frente al código de presentación, etc.No me malinterpretes, también se necesitan estándares de bajo nivel (¡el formato es importante para la legibilidad!). Simplemente tengo una inclinación hacia la estructura general.

Otro aspecto 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 lo más importante) nadie los hace cumplir, entonces todo será en vano.

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

Reglas SSW

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

Lo más probable es que esté preparado para fracasar.Bienvenido a la industria.

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

Si otras personas tienen problemas con el contenido, puedes pedirles que lo actualicen para mostrar lo que prefieren.De esa manera, usted se librará de ello y los demás tendrán la responsabilidad de justificar sus cambios.

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

Otra fuente puede ser Directrices de codificación profesional en C#/VB .NET.

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 le brinda la regla, sino que también explica el motivo detrás de la regla e incluso proporciona una antirregla donde podrían 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 "Usar StyleCop".

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

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

He usado Juval antes y eso es suficiente, si no excesivo, pero soy un vago y ahora simplemente me conformo con la voluntad de Reafilador.

Puede consultar esto: Los 7 principales estándares de codificación y documentos de directrices 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 pautas de MS ya vinculadas son un excelente punto de partida.Modelo mi código en gran medida sobre esos.

Lo cual es interesante porque mi manager me dijo en el pasado que no le gustan mucho :D

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

El estándar de Philips Medical Systems está bien redactado 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 está un poco anticuado).

También sigo a Resharper.También la línea 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.aspxYhttp://csharpguidelines.codeplex.com/releases/view/46280

En el código que escribo suelo seguir Directrices de diseño de .NET Framework para API expuestas públicamente y Directrices de codificación mono para carcasa y sangría de miembros privados.Mono es una implementación de código abierto de .NET y creo que esa gente conoce 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 resultarle extraño en las pautas Mono es que utilizan 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 impongas nada de eso si a tus compañeros de trabajo no les gusta (a menos que estés dispuesto a contribuir a Mono ;-)

Licenciado bajo: CC-BY-SA con atribución

No afiliado a StackOverflow