Si crees que no debería, explica por qué.¿Cree que una empresa de software debería imponer a los desarrolladores un estilo de codificación?
En caso afirmativo, ¿qué profundidad deberían tener las pautas en su opinión? Por ejemplo, ¿debe incluirse la sangría del código?
creo un equipo (en lugar de una empresa ) tienen que ponerse de acuerdo sobre un conjunto de directrices para el estilo razonablemente consistente. Lo hace más sencillo para el mantenimiento.
¿Qué tan 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.
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 molestia dada IDEs de hoy y sus capacidades de autoformato.
P.S: Tengo este hábito molesto de poner mis llaves en la próxima línea :). A nadie más parece gustarle
yo también, cuando si (condición) {} ... rompe su mucho más fácil para comprobar los apoyos correctos cuando está en el lado del producto y adecuadamente sangría. – UnkwnTech
¡Yo también! Creo que hace que la depuración sea mucho más fácil. Esto es aún más importante cuando tiene un calendario apretado y necesita corregir un error CUANTO ANTES. ¡No tengo tiempo para luchar con la sintaxis! –
En mi opinión, creo que es muy necesario con las normas 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 me encanta 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).
Creo que los programadores deberían ser capaces de 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.
While I don't agree with everything, this book contains an excellent starting point for standards
Sí, pero dentro de lo razonable.
Todos los IDEs modernos ofrecen un código de una pulsación bastante impresión, 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 pequeños parámetros de "salida" o "ref" como sea posible ... En este ejemplo, tiene 2 ventajas: mejora la legibilidad y también corrige una gran cantidad de errores (muchos de los parámetros de salida son un olor a código y probablemente deberían ser refactorizados).
Ir más allá de eso es, en mi opinión honesta, un poco "anal" e innecesariamente molesto para los desarrolladores.
Buen punto por Hamish Smith:
estilo es muy diferente de mejores prácticas . Es una pena que los 'estándares de codificación ' tiendan a rodar los dos juntos. Si las personas pudieran mantener la pieza de estilo al mínimo, se concentraría en las mejores prácticas que probablemente agregarían más valor.
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. –
Desea que todos lean y escriban código de manera estándar. Hay dos maneras de lograr esto:
Cuanto más deje indefinido, mayor será la probabilidad de que uno de los desarrolladores choque con el estilo.
Hrm, alguien borró mi comentario. Es ridículo mencionar la clonación. Mi comentario exacerbó eso. Si se elimina, también debe ser la publicación, o al menos editada. Wow, habla sobre el control. – mattlant
mattlant: seconded. Si haces algo negativo en este sitio (votar, eliminar comentarios, cerrar publicaciones, etc.) definitivamente deberías dejar un maldito comentario explicando por qué. Tu comentario fue gracioso y no causó ningún daño. – Oli
La compañía debe 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, muescas, nombres, etc ... Escribe el 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 usted está en .Net vistazo a StyleCop, FxCop y ReSharper
Estoy de acuerdo. Una herramienta hará que sea más fácil cumplir con el estándar y verificar el cumplimiento. También es más difícil discutir con la herramienta;) –
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.
Claro, las pautas son buenas, y a menos que sea una notación húngara mal utilizada (¡ja!), Probablemente mejorará la consistencia y hará que sea más fácil leer el 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 utilizar nombres como temp, pero lo que no puedes hacer es forzarme a tener espacios alrededor de valores de índice en corchetes de la matriz (lo intentaron una vez ...)
Hay Hay muchas buenas razones para que los estándares definan la forma en que se desarrollan las aplicaciones y la forma en que debería 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 :
En una empresa de subcontratación, se podría hacer una excepción para un equipo que trabaja para un cliente si el cliente desea 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.
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: consistencia en estándares comenzando desde 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.
These 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 configura ninguno, habrá enfrentamientos entre desarrolladores y problemas de legibilidad.
Tener el código uniforme hasta el final 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 " compañía "y también ayuda con la legibilidad dentro del equipo ...
Un estilo de codificación común promueve la coherencia y hace que sea fácil para diferentes personas entender, mantener y expandir fácilmente todo el código base, 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ápidamente. 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 (en orden):
También, tener cuidado con los programadores que pueden o no quieren adaptarse al estilo del equipo, no importa qué tan brillante que podría ser. Si no juegan según una de las reglas del equipo, probablemente no jueguen según otras reglas del equipo.
¿Cree que una empresa de software debería imponer a los desarrolladores un estilo de codificación?
No de forma descendente. 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 deben 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, ¿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) cantidad de caracteres de espacio. Además, acuerde un margen (por ejemplo, 76 caracteres o 120 caracteres) para las líneas largas.
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).
que sugeriría la estandarización de al menos los siguientes (en orden decreciente de importancia):
El b La solución est 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.
Mi opinión:
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 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.
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.
Todas las empresas deberían. 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 (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.
Cada idioma tiene estándares generales que utiliza 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 una norma oficial es incorrecta porque una norma de codificación de la empresa suele ser demasiado rígida y no puede fluir con la comunidad general utilizando el idioma.
Si tiene un problema con un miembro del equipo que realmente está por ahí en el estilo de codificación, eso es algo excelente para el grupo sugerir suavemente 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.
Normas de diseño: 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.
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.
Estoy totalmente de acuerdo en que se deben aplicar estándares de codificación, y que casi siempre debe ser a nivel de equipo. Sin embargo, hay un par de excepciones.
Si el equipo está escribiendo código que será utilizado por otros equipos (y quiero decir que otros equipos tendrán que ver la fuente, no solo usarla como biblioteca), entonces hay beneficios en hacer estándares comunes en todos los equipos que lo usan. 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.
Al igual que otros han mencionado, creo que debe ser por ingeniería o por el equipo: la empresa (es decir, las unidades de negocio) no debe participar en ese tipo de decisión.
Pero otra cosa que agregaría es que las reglas que se implementan deben ser impuestas por las herramientas y no por 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.
Entonces, surge algún conflicto, y alguien se pone 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 tener advertencias lanzadas 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.
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 solo, secuencialmente, como cuando recogían las piezas de un proyecto anterior). No tener un sistema de convención dentro de una empresa solo es 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 diseñado para el bien y no el 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 se trata de una 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 recoja las cosas buenas y continúe con ellas.
No creo que un equipo de desarrollo deba tener pautas de estilo que deben seguir como regla general. Hay excepciones, por ejemplo the use of <> vs. "" in #include statements, 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é son necesarias las pautas de estilo 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 va a estar empantanado cuando ven esto:
for(int n = 0; n < 42; ++42) {
// blah
}
... cuando ellos están acostumbrados a ver esto:
for(int n = 0; n < 42; ++42)
{
// blah
}
Por otra parte, he encontrado que en realidad es más fácil mantenga el código en algunos casos si puede 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.
Por último, si Joe tarda 10 minutos en retroceder & moviendo 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 resultaba natural. ?
Hay dos tipos de convenciones.
tipo A convenciones: "Por favor éstos, es mejor"
y Tipo B: "Por favor, maneje en el lado derecho de la carretera", mientras que es bien para conducir en el otro lado, como se siempre y cuando todos hagan lo mismo.
No existe un equipo aparte. 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.
Su respuesta resume exactamente mis experiencias. Los equipos deben definir sus estándares, lo que tiene la ventaja de que cada miembro del equipo tiene algo que decir (llamamos a eso "buy-in"). El líder de nuestro equipo rara vez tomaba una decisión "dictatorial" sobre el estilo, siempre se discutía hasta que se alcanzaba un consenso. –
No estoy de acuerdo. Después de las personas, el recurso más preciado de una empresa de software es el código. Es necesario que haya estándares entre los equipos, de lo contrario, cada equipo se convierte en una isla cada vez más. ¿Y qué sucede cuando un miembro del equipo se muda a otro equipo? Oh, nuevos "estándares" –
He encontrado solo a través de la experiencia personal y trabajando con varios equipos que el estilo más fácil de promover es uno que es el más estúpido. Es decir, evite enamorarse con formatos exóticos, esquemas de nombres, etc., toda la filosofía de KISS. Para aquellos de nosotros que hemos tenido que trabajar con código de una gran variedad de autores, nos acostumbramos a muchos estilos diferentes ... excepto a los realmente exóticos que simplemente presentan todo tipo de convenciones y estilos de formato nuevos. Olvídate un poco y será mucho más fácil para todos nosotros estar en la misma página. – stinky472