coding-style - software - practicas de javascript

¿Crees que una empresa de software debería imponer a los desarrolladores un estilo de codificación? (28)

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

No de una manera vertical. Los desarrolladores de una empresa de software deberían acordar un estilo de codificación común.

En caso afirmativo, ¿qué profundidad deberían tener las pautas en su opinión?

Solo deberían describir las diferencias de las convenciones 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, ¿debe incluirse la sangría del 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) cantidad de caracteres de espacio. Además, acuerde un margen (por ejemplo, 76 caracteres o 120 caracteres) para las líneas largas.

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

En caso afirmativo, ¿qué profundidad deberían tener las pautas en su opinión? Por ejemplo, ¿debe incluirse la sangría del código?

Cada idioma tiene estándares generales que usa la comunidad. Debes seguirlos tan bien como sea posible para que tu código pueda ser mantenido por otras personas acostumbradas al idioma, pero no hay necesidad de ser dictatorial al respecto.

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

Si está teniendo un problema con un miembro del equipo que realmente está en el estilo de codificación, eso es algo excelente para el grupo sugerir suavemente que no es una buena idea en una revisión de código.

Claro, las pautas son buenas, y a menos que sea una notación húngara mal utilizada (¡ja!), Probablemente mejorará la uniformidad y facilitará la lectura del código de otras personas. Sin embargo, las pautas deberían ser solo pautas, no reglas estrictas aplicadas a los programadores. Podrías decirme dónde poner mis llaves o no usar nombres como temp, pero lo que no puedes hacer es forzarme a tener espacios alrededor de los valores de índice en corchetes de la matriz (lo intentaron una vez ...)

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 compañía. Sería bueno si todos pudiéramos hacer lo nuestro; sin embargo, si todos codificamos a lo largo de algunas directrices de bast, esto 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

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

Además, no es una gran molestia dado IDEs de hoy y sus capacidades de auto-formato.

PD: Tengo este hábito molesto de poner mis llaves en la siguiente línea :). A nadie más parece gustarle

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.

¿Que profundo? Tan superficial como puedas estar de acuerdo. Cuanto más corto y más claro es, más probable es que todos los miembros del equipo puedan aceptarlo y lo cumplan.

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

Clone a un único desarrollador varias veces y asegúrese de que todos pasen por la misma capacitación. Esperemos que todos puedan escribir la misma base de código.
Proporcione a sus desarrolladores actuales instrucciones explícitas sobre lo que necesita. Pestañas o espacios para sangría. Donde los apoyos se sientan. Cómo comentar Lineamientos de compromiso de control de versiones.

Cuanto más deje indefinido, mayor será la probabilidad de que uno de los desarrolladores choque con el estilo.

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

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

Estoy de acuerdo en que la coherencia 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 gustarle el uso de un IDE, y porque cuando está 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 un roll-back luego para que su VCS no intente confirmar todos los cambios (obstruyendo el repositorio con actualizaciones innecesarias que son una carga para todos).

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

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)
Nombrar (archivos y carpetas, clases, funciones, variables, ...)
Comentando (usando un formato que permite la generación automática de documentación)

Existen muchos buenos motivos para que los estándares definan la forma en que se desarrollan las aplicaciones y la forma en que debe verse el código. Por ejemplo, cuando todos usan el mismo estándar, se puede usar un corrector 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 volver a factorizar el mismo código de diferentes maneras. Por lo tanto:

Todo el código desarrollado por el equipo 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 que pertenecen 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 trabaje para un cliente si el cliente quiere aplicar 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.

La compañía debería imponer que se siga cierto estilo. El estilo que es y cuán profundas son las directrices debe ser decidido colectivamente por la comunidad de desarrolladores de la empresa.

Definitivamente estableceré pautas sobre llaves, indentación, nombres, etc. Escribe código para legibilidad y facilidad de mantenimiento. Siempre suponga que alguien más va a leer su código. Existen herramientas que formatearán automáticamente su código, y puede exigir que todos utilicen la herramienta.

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

La mejor solución sería que los IDE consideren ese 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 debe ser configurable sin cambiar el archivo de origen.

Los IDE modernos te 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 que ingresen su código. Si quiere ser aún más riguroso al respecto, puede agregar un enlace de compromiso para su sistema de control de versiones para sangrar el código antes de que sea aceptado.

Mi opinión:

Algunas reglas básicas son buenas ya que ayudan a todos a leer y mantener el código
Demasiadas reglas son malas ya que detienen a los desarrolladores innovando 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 Diff / culpa pero la pista sigue siendo útil

Sí, creo que las empresas deberían. 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 Midhat dijo: es importante tener una base de código consistente.

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 debería ser el nombre y la organización de su código. Esto ayuda mucho al integrar componentes de código abierto en su proyecto.

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

Sí, pero dentro de lo razonable.

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

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

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

Buen punto por Hamish Smith:

El estilo es bastante diferente de las mejores prácticas. Es una pena que los ''estándares de codificación'' tiendan a unir los dos. Si las personas pudieran mantener el estilo al mínimo y concentrarse en las mejores prácticas que probablemente agregarían más valor.

Sí.

Los estándares de codificación son una forma común de garantizar que el código dentro de una organización determinada siga el Principio de la menor sorpresa: la coherencia en los estándares, comenzando con la nomenclatura variable hasta 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.

Toda empresa debería. El estilo de codificación coherente 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 la mesa e imponer algún tipo de pautas de codificación estandarizadas.

Un estilo de codificación común promueve la coherencia y hace que sea fácil para diferentes personas comprender, mantener y expandir fácilmente toda la base de código, no solo sus propias piezas. También hace que sea más fácil para las personas nuevas aprender 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):

espacio en blanco y sangría
comentarios estándar: encabezados de archivo, clase o método
convención de nombres: 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. usar
manejo de errores - excepciones, hresults, códigos de error
Enhebrado y sincronización

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

Estos son los estándares de codificación para una empresa para la que solía trabajar. Están bien definidos, y, aunque me tomó un tiempo acostumbrarme a ellos, significaba que el código podía leerse por todos nosotros, y que era uniforme durante todo el proceso.

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

Tener el código uniforme durante todo el proceso presenta un mejor código para el usuario final (por lo que parece como si hubiera sido escrito por una persona, que, desde el punto de vista de los usuarios finales, debería ser esa persona "la compañía" y también ayuda con la legibilidad dentro del equipo ...

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

Estándares de estilo: NO. Tu legible, es mi basura desconcertante, y viceversa. Los buenos comentarios y el factoring de código tienen un beneficio mucho mayor. También gnu indent.

Al igual que otros han mencionado, creo que debe ser por ingeniería o por el equipo: la compañía (es decir, las unidades de negocios) no debe participar en ese tipo de decisión.

Pero otra cosa que agregaría es que las reglas que se implementan deben ser aplicadas por las herramientas y no por las personas. En el peor de los casos, IMO, es un esnob de la gramática demasiado celoso (sí, existimos, lo sé porque podemos oler el nuestro) escribe algunos documentos que describen un conjunto de pautas de codificación que absolutamente nadie lee ni sigue. Se vuelven obsoletos con el tiempo, y a medida que se agregan nuevas personas al equipo y los ancianos se van, simplemente se vuelven obsoletos.

Luego, surge un conflicto y alguien se ve en la incómoda posición de tener que confrontar a alguien sobre el estilo de codificación: este tipo de confrontación debe hacerse con herramientas y no con 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 (nuevamente, IMO) es lanzar advertencias en tiempo de compilación (o algo similar), siempre y cuando su entorno de compilación lo admita. No es difícil configurar esto en VS.NET, pero desconozco otros entornos de desarrollo que tienen características similares.

Estoy totalmente de acuerdo en que los estándares de codificación deberían aplicarse, y que casi siempre deberían 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 me refiero a que otros equipos tendrán que mirar la fuente, no solo usarla como biblioteca), entonces hay beneficios en hacer estándares comunes en todos los equipos. usándolo De manera similar, si la política de la compañía es mover con frecuencia a los programadores de un equipo a otro, o si un equipo con frecuencia quiere reutilizar el código de otro equipo, probablemente sea mejor imponer estándares en toda la empresa.

Las pautas de estilo son extremadamente importantes, ya sea para diseño o desarrollo, porque aceleran la comunicación y el rendimiento de las personas que trabajan en colaboración (o incluso a solas, secuencialmente, como cuando recogen las piezas de un proyecto anterior). No tener un sistema de convención dentro de una compañía es simplemente pedirle a las personas que sean tan improductivas como puedan. La mayoría de los proyectos requieren colaboración, e incluso aquellos que no lo hacen pueden ser vulnerables a nuestro deseo natural de ejercitar nuestras chuletas de programación y mantenerse al día. Nuestro deseo de aprender interfiere con nuestra coherencia, que es algo bueno en sí mismo, pero que puede volver loco a un nuevo empleado al tratar de aprender los sistemas en los que se está metiendo.

Como cualquier otro sistema que sea para bien y no mal, el verdadero poder de la guía está en las 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 lo más profundas que 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 es solo una GUÍA.

RTFM, luego recoge las cosas buenas y sigue adelante.

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 pasa o falla sería más flexible y efectivo que simplemente documentar un estándar.

Hay dos tipos de convenciones.

Convenciones tipo A: "por favor haz 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 hay tal cosa como 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 debe ser capaz de respetar las prácticas de la base de código existente y seguirlas.

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 <> frente a "" en las declaraciones #include , pero estas excepciones deben provenir de la necesidad.

La razón más común que escucho que las personas usan 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 empantanará 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 puedes identificar al programador que escribió el código original simplemente reconociendo su estilo. Ve y pregúntales por qué implementaron el gizmo de una manera tan enrevesada en 10 minutos en lugar de pasar la mayor parte del día averiguando la razón muy 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 a Joe le toma 10 minutos retroceder y mover sus llaves para que Bill pueda pasar 3 segundos menos mirando el código, ¿realmente ahorró tiempo para hacer que Bill hiciera algo que no le resulta natural?