¿Crees que una empresa de software debería imponer a los desarrolladores un estilo de codificación? [cerrado]

https://stackoverflow.com/questions/145508

02-07-2019
|

Pregunta

Si crees que no debería, explica por qué.

En caso afirmativo, ¿qué tan profundas deberían ser las pautas en su opinión? Por ejemplo, ¿se debe incluir una sangría de código?

Solución

Creo que un equipo (en lugar de una empresa ) necesita acordar un conjunto de pautas para un estilo razonablemente consistente. Lo hace más sencillo para el mantenimiento.

¿Qué tan profundo? Tan superficial como puedas acordar. Cuanto más corto y claro sea, más probable es que todos los miembros del equipo puedan aceptarlo y cumplirlo.

Otros consejos

Quiere que todos lean y escriban código de manera estándar. Hay dos formas de lograr esto:

Clone un solo desarrollador varias veces y asegúrese de que todos pasen por el mismo entrenamiento. Esperemos que todos puedan escribir la misma base de código.
Dé a sus desarrolladores existentes instrucciones explícitas sobre lo que necesita. Pestañas o espacios para sangría. Donde se sientan los aparatos ortopédicos. Cómo comentar Directrices de confirmación de control de versiones.

Cuanto más dejes indefinido, mayor será la probabilidad de que uno de los desarrolladores se enfrente con el estilo.

La compañía debería imponer que se debe seguir algún estilo. La comunidad de desarrolladores de la empresa debe decidir colectivamente qué estilo es y qué tan profundas son las pautas.

Definitivamente establecería pautas sobre llaves, sangrado, nombres, etc. Usted escribe código para facilitar la lectura y el mantenimiento. Siempre asuma que alguien más va a leer su código. Existen herramientas que formatearán automáticamente su código mágicamente, y puede exigir que todos usen la herramienta.

Si estás en .Net, mira stylecop, fxcop y Resharper

¿Crees que una compañía de software debería imponer a los desarrolladores un estilo de codificación?

No de arriba hacia abajo. Los desarrolladores de una empresa de software deben acordar un estilo de codificación común.

En caso afirmativo, ¿qué tan profundas deberían ser las pautas en su opinión?

Solo deberían describir las diferencias de las convenciones bien conocidas, tratando de mantener la desviación mínima. Esto es fácil para lenguajes como Python o Java, algo borroso para C / C ++ y casi imposible para Perl y Ruby.

Por ejemplo, ¿se debe incluir una sangría de código?

Sí, hace que el código sea mucho más legible. Mantenga la sangría consistente en términos de espacios frente a pestañas y (si opta por espacios) número de caracteres de espacio. Además, acuerde un margen (por ejemplo, 76 caracteres o 120 caracteres) para líneas largas.

Sí, pero dentro de lo razonable.

Todos los IDEs modernos ofrecen un código de una sola pulsación de letra bonita, por lo que " sangría " punto es bastante irrelevante, en mi opinión.

Lo que es más importante es establecer las mejores prácticas: por ejemplo, use como " out " o " ref " parámetros como sea posible ... En este ejemplo, tiene 2 ventajas: mejora la legibilidad y también corrige muchos errores (muchos parámetros son un olor a código y probablemente deberían ser refactorizados).

Ir más allá de eso es, en mi sincera opinión, un poco " anal " e innecesariamente molesto para los desarrolladores.

Buen punto de Hamish Smith:

El estilo es bastante diferente del mejor prácticas Es una pena que la codificación los estándares tienden a rodar los dos juntos. Si la gente pudiera mantener el parte de estilo al mínimo y concentrarse en las mejores prácticas que probablemente agregaría más valor.

No creo que un equipo de desarrollo deba tener pautas de estilo que deben seguir como regla general. Hay excepciones, por ejemplo el uso de & Lt; & Gt; vs. " " en #incluir declaraciones , pero estas excepciones deben provenir de la necesidad.

La razón más común por la que escucho que la gente usa para explicar por qué las pautas de estilo son necesarias es que el código escrito en un estilo común es más fácil de mantener ese código escrito en estilos individuales. Estoy en desacuerdo. Un programador profesional no se atascará cuando vea esto:

for( int n = 0; n < 42; ++42 ) {
 // blah
}

... cuando están acostumbrados a ver esto:

for(int n = 0; n < 42; ++42 )
{
 // blah
}

Además, he descubierto que en realidad es más fácil mantener el código en algunos casos si puede identificar al programador que escribió el código original simplemente reconociendo su estilo. Pregúnteles por qué implementaron el artilugio de una manera tan complicada en 10 minutos en lugar de pasar la mayor parte del día descubriendo la razón técnica por la que hicieron algo inesperado. Es cierto que el programador debería haber comentado el código para explicar su razonamiento, pero en el mundo real los programadores a menudo no lo hacen.

Finalmente, si le toma a Joe 10 minutos retroceder & amp; moviendo sus llaves para que Bill pueda pasar 3 segundos menos mirando el código, ¿realmente ahorró tiempo hacer que Bill hiciera algo que no le resulta natural?

Creo que tener una base de código consistente es importante. Aumenta la capacidad de mantenimiento de su código. Si todos esperan el mismo tipo de código, pueden leerlo y comprenderlo fácilmente.

Además, no es una gran molestia dados los IDE de hoy y sus capacidades de autoformación.

P.S: Tengo esta molesta costumbre de poner mis aparatos ortopédicos en la siguiente línea :). A nadie más parece gustarle

Creo que los programadores deberían poder adaptarse al estilo de otros programadores. Si un nuevo programador no puede adaptarse, eso generalmente significa que el nuevo programador es demasiado terco para usar el estilo de la empresa. Sería bueno si todos pudiéramos hacer lo nuestro; sin embargo, si todos codificamos siguiendo alguna directriz de bast, facilita la depuración y el mantenimiento. Esto solo es cierto si el estándar está bien pensado y no es demasiado restrictivo.

Si bien no estoy de acuerdo con todo, este libro contiene un excelente punto de partida para los estándares

La mejor solución sería que los IDE consideren dicho formato como metadatos. Por ejemplo, la posición de la llave de apertura (línea actual o línea siguiente), la sangría y el espacio en blanco alrededor de los operadores deben ser configurables sin cambiar el archivo fuente.

En mi opinión, creo que es muy necesario con estándares y guías de estilo. Porque cuando tu base de código crezca querrás que sea consistente.

Como nota al margen, es por eso que amo Python; porque ya impone muchas reglas sobre cómo estructurar sus aplicaciones y demás. Compare eso con Perl, Ruby o lo que sea donde tenga una libertad extrema (que no es tan bueno en este caso).

Hay muchas buenas razones para que los estándares definan la forma en que se desarrollan las aplicaciones y el aspecto del código. Por ejemplo, cuando todos usan el mismo estándar, se puede usar un verificador de estilo automático como parte del CI del proyecto. El uso de los mismos estándares mejora la legibilidad del código y ayuda a reducir la tensión entre los miembros del equipo sobre la refactorización del mismo código de diferentes maneras. Por lo tanto:

Todo el código desarrollado por el equipo en particular debe seguir exactamente el mismo estándar.
Todo el código desarrollado para un proyecto en particular debe seguir exactamente el mismo estándar.
Es deseable que los equipos pertenecientes a la misma empresa utilicen el mismo estándar.

En una empresa de outsourcing se podría hacer una excepción para un equipo que trabaja para un cliente si el cliente quiere hacer cumplir un estándar propio. En este caso, el equipo adopta el estándar del cliente que podría ser incompatible con el utilizado por su empresa.

Como otros han mencionado, creo que debe ser por ingeniería o por el equipo: la empresa (es decir, las unidades de negocio) no debería participar en ese tipo de decisión.

Pero otra cosa que agregaría es que cualquier regla que se implemente debe ser aplicada por herramientas y no por las personas. En el peor de los casos, la OMI, es un snob de gramática demasiado entusiasta (sí, existimos; lo sé porque podemos oler el nuestro) escribe una documentación que describe un conjunto de pautas de codificación que absolutamente nadie lee o sigue. Con el tiempo, se vuelven obsoletas y, a medida que se agregan nuevas personas al equipo y las personas mayores se van, simplemente se vuelven obsoletas.

Entonces, surge un conflicto, y alguien se pone en la incómoda posición de tener que confrontar a otra persona sobre el estilo de codificación: este tipo de confrontación debe hacerse mediante herramientas y no por personas. En resumen, este método de aplicación es el menos deseable, en mi opinión, porque es demasiado fácil de ignorar y simplemente le ruega a los programadores que discutan sobre cosas estúpidas.

Una mejor opción (de nuevo, IMO) es lanzar advertencias en tiempo de compilación (o algo similar), siempre que su entorno de compilación lo admita. No es difícil configurar esto en VS.NET, pero no conozco otros entornos de desarrollo que tengan características similares.

Las pautas de estilo son extremadamente importantes, ya sea para el diseño o el desarrollo, porque aceleran la comunicación y el rendimiento de las personas que trabajan en colaboración (o incluso solas, de forma secuencial, como cuando recogen las piezas de un proyecto antiguo). No tener un sistema de convenciones dentro de una empresa es solo pedirles a las personas que sean tan improductivas como puedan. La mayoría de los proyectos requieren colaboración, e incluso aquellos que no pueden ser vulnerables a nuestro deseo natural de ejercer nuestras habilidades de programación y mantenerse al día. Nuestro deseo de aprender se interpone en el camino de nuestra consistencia, lo cual es algo bueno en sí mismo, pero puede volver loco a un nuevo empleado tratando de aprender los sistemas en los que se está metiendo.

Al igual que cualquier otro sistema destinado al bien y no al mal, el verdadero poder de la guía está en manos de su gente. Los propios desarrolladores determinarán cuáles son las partes esenciales y útiles y luego, con suerte, las usarán.

Como la ley. O el idioma inglés.

Las guías de estilo deben ser tan profundas como quieran; si aparece en la sesión de lluvia de ideas, debe incluirse. Es extraño cómo formuló la pregunta porque al final del día no hay forma de & "; Imponer &"; una guía de estilo porque solo es una GUÍA.

RTFM, luego recoge las cosas buenas y sigue adelante.

Sí, creo que las empresas deberían hacerlo. El desarrollador puede necesitar acostumbrarse al estilo de codificación, pero en mi opinión, un buen programador debería poder trabajar con cualquier estilo de codificación. Como dijo Midhat: es importante tener una base de código coherente.

Creo que esto también es importante para los proyectos de código abierto, no hay un supervisor que le diga cómo escribir su código, pero muchos idiomas tienen especificaciones sobre cómo debe ser la denominación y la organización de su código. Esto ayuda mucho al integrar componentes de código abierto en su proyecto.

Claro, las pautas son buenas y, a menos que sea una notación húngara mal utilizada (¡ja!), probablemente mejorará la coherencia y facilitará la lectura del código de otras personas. Sin embargo, las pautas deberían ser pautas, no reglas estrictas impuestas a los programadores. Podría decirme dónde poner mis llaves o no usar nombres como temp, pero lo que no puede hacer es obligarme a tener espacios alrededor de los valores de índice entre paréntesis (lo intentaron una vez ...)

Sí.

Los estándares de codificación son una forma común de garantizar que el código dentro de una determinada organización siga el Principio de Menos Sorpresa: consistencia en los estándares que comienzan desde el nombre variable hasta la sangría y el uso de llaves.

Los codificadores que tienen sus propios estilos y sus propios estándares solo producirán una base de código que es inconsistente, confusa y frustrante de leer, especialmente en proyectos más grandes.

Estos son los estándares de codificación para una empresa para la que solía trabajar. Están bien definidos y, si bien me llevó un tiempo acostumbrarme a ellos, significaba que el código era legible para todos nosotros y uniforme en todo momento.

Creo que los estándares de codificación son importantes dentro de una empresa, si no se establece ninguno, habrá conflictos entre desarrolladores y problemas de legibilidad.

Tener el código uniforme hasta el final presenta un código mejor para el usuario final (por lo que parece que fue escrito por una persona, lo que, desde el punto de vista de los Usuarios finales, debería) esa persona es " la compañía " y también ayuda con la legibilidad dentro del equipo ...

Un estilo de codificación común promueve la coherencia y facilita que diferentes personas comprendan, mantengan y expandan fácilmente toda la base del código, no solo sus propias piezas. También facilita que las personas nuevas aprendan el código más rápido. Por lo tanto, cualquier equipo debe tener una guía sobre cómo se espera que se escriba el código.

Las pautas importantes incluyen (sin ningún orden en particular):

espacios en blanco e indentación
comentarios estándar - encabezados de archivo, clase o método
convención de nomenclatura: clases, interfaces, variables, espacios de nombres, archivos
anotaciones de código
organización del proyecto - estructuras de carpetas, binarios
bibliotecas estándar: qué plantillas, genéricos, contenedores, etc. utilizar
manejo de errores: excepciones, resultados, códigos de error
subprocesos y sincronización

Además, tenga cuidado con los programadores que no pueden o no se adaptarán al estilo del equipo, sin importar cuán brillantes sean. Si no juegan con una de las reglas del equipo, probablemente tampoco jugarán con otras reglas del equipo.

Estoy de acuerdo en que la consistencia es la clave. No puede confiar en la impresión bonita de IDE para salvar el día, porque a algunos de sus desarrolladores puede no gustarles usar un IDE, y porque cuando están rastreando una base de código de miles de archivos fuente, simplemente no es factible imprima todos los archivos cuando comience a trabajar en ellos y realice una reversión después para que su VCS no intente confirmar todos los cambios (obstruyendo el repositorio con actualizaciones innecesarias que agobian a todos).

Sugeriría estandarizar al menos lo siguiente (en orden de importancia decreciente):

Espacio en blanco (es más fácil si elige un estilo que se ajuste a la impresión bonita automática de alguna herramienta compartida)
Naming (archivos y carpetas, clases, funciones, variables, ...)
Comentarios (usando un formato que permite la generación automática de documentación)

Mi opinión:

Algunas reglas básicas son buenas ya que ayuda a todos a leer y mantener el código
Demasiadas reglas son malas ya que impide que los desarrolladores innoven con formas más claras de diseñar código
El estilo individual puede ser útil para determinar el historial de un archivo de código. Se pueden usar herramientas de diferencia / culpa, pero la sugerencia sigue siendo útil

Los IDE modernos le permiten definir una plantilla de formato. Si hay un estándar corporativo, desarrolle un archivo de configuración que defina todos los valores de formato que le interesan y asegúrese de que todos ejecuten el formateador antes de ingresar su código. Si desea ser aún más riguroso al respecto, puede agregar un enlace de confirmación para su sistema de control de versiones para sangrar el código antes de que sea aceptado.

Sí en términos de uso de un estándar de nomenclatura común, así como un diseño común de clases y código detrás de los archivos. Todo lo demás está abierto.

Toda empresa debería. El estilo de codificación constante garantiza una mayor legibilidad y facilidad de mantenimiento de la base de código en todo su equipo.

La tienda en la que trabajo no tiene un estándar de codificación unificado, y puedo decir que nosotros (como equipo) sufrimos mucho de eso. Cuando no hay voluntad de los individuos (como en el caso de algunos de mis colegas), el líder del equipo tiene que golpear su puño sobre la mesa e imponer alguna forma de pautas de codificación estandarizadas.

Ever language tiene estándares generales que son utilizados por la comunidad. Debe seguirlos lo mejor posible para que otras personas acostumbradas al lenguaje puedan mantener su código, pero no hay necesidad de ser dictatorial al respecto.

La creación de un estándar oficial es incorrecta porque el estándar de codificación de una empresa suele ser demasiado rígido y no puede fluir con la comunidad en general utilizando el lenguaje.

Si tiene un problema con un miembro del equipo que realmente está presente en el estilo de codificación, es una excelente idea que el grupo sugiera gentilmente que no es una buena idea en una revisión de código.

Estándares de codificación: SÍ. Por razones ya cubiertas en este hilo.

Estándares de estilo: NO. Su legible, es mi basura desconcertante, y viceversa. Los buenos comentarios y factorización de código tienen un beneficio mucho mayor. También sangría ñu.

Me gusta la respuesta de Ilya porque incorpora la importancia de la legibilidad y el uso de la integración continua como mecanismo de aplicación. Hibri mencionó FxCop, y creo que su uso en el proceso de compilación como uno de los criterios para determinar si una compilación se aprueba o falla sería más flexible y eficaz que simplemente documentar un estándar.

Estoy totalmente de acuerdo en que los estándares de codificación deben aplicarse, y que casi siempre debe ser a nivel de equipo. Sin embargo, hay un par de excepciones.

Si el equipo está escribiendo un código que será utilizado por otros equipos (y aquí quiero decir que otros equipos tendrán que mirar la fuente, no solo usarlo como una biblioteca), entonces hay beneficios al hacer estándares comunes en todos todos los equipos que lo usan. Del mismo modo, si la política de la empresa es trasladar con frecuencia a los programadores de un equipo a otro, o está en una posición en la que un equipo con frecuencia quiere reutilizar el código de otro equipo, entonces probablemente sea mejor imponer estándares en toda la empresa.

Hay dos tipos de convenciones.

Convenciones de tipo A: " haga esto, es mejor "

y Tipo B: " conduzca por el lado derecho de la carretera " ;, mientras que está bien conducir por el otro lado, siempre y cuando todos hagan lo mismo.

No existe un equipo separado. Todo el código en una buena empresa está conectado de alguna manera, y el estilo debe ser consistente. Es más fácil acostumbrarse a un nuevo estilo que a veinte estilos diferentes .

Además, un nuevo desarrollador debería poder respetar las prácticas de la base de código existente y seguirlas.

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

No afiliado a StackOverflow