Este documento de estilo de programación tiene una regla general que dice:
Las reglas pueden ser violadas si hay fuertes objeciones personales en su contra.
Esto choca con la forma en que estoy pensando, y hay muchos artículos que dicen que el estilo de codificación es realmente importante. Por ejemplo esto dice:
Un documento de estándares de codificación les dice a los desarrolladores cómo deben escribir su código. En lugar de que cada desarrollador codifique en su propio estilo preferido, escribirán todo el código según los estándares descritos en el documento. Esto asegura que un proyecto grande esté codificado en un estilo consistente: las partes no están escritas de manera diferente por diferentes programadores. Esta solución no solo hace que el código sea más fácil de entender, sino que también garantiza que cualquier desarrollador que lo vea sepa qué esperar en toda la aplicación.
Entonces, ¿estoy malinterpretando algo de este documento y la cita al principio de esta pregunta? ¿Puede la gente realmente ignorar el estilo de codificación?
Tal vez no fui lo suficientemente claro, así que con esta edición, voy a aclarar un poco.
Estoy escribiendo el documento de estilo de codificación para nuestro equipo, y quiero verificar el estilo usando algunos analizadores estáticos. Si falla, Jenkins enviará correos electrónicos. Y quiero fallar la revisión del código, si el estilo no coincide. Esto claramente choca con la primera cita.
Pero entonces, si la cita es correcta, ¿de qué sirve el documento de estilo de codificación, si alguien puede hacer lo que quiera?
fuente
Respuestas:
Por lo que puedo decir, la declaración que lo confundió es un compromiso pragmático hecho para que las pautas sirvan a la audiencia más amplia posible. Dependiendo de su contexto específico (más sobre eso a continuación) puede tener una opción para ajustarlo y hacer un uso más eficiente de las pautas.
Verá, las pautas se refieren a "fuertes objeciones personales" como un medio para justificar la violación. Tales objeciones no son algo que ignorar a la ligera, especialmente si provienen de desarrolladores experimentados.
Estas objeciones pueden estar equivocadas, pero (y esto es muy, pero MUY GRANDE) también pueden indicar que una regla en particular está mal, ya sea en general o en el contexto específico del proyecto (un ejemplo de desajuste de la regla es un requisito para proporcionar registro detallado en el código crítico de rendimiento).
Creo que cualquier guía de estilo sensata debería tener en cuenta lo anterior e intentar acomodar una posible necesidad de ajustarse. Ahora, si la guía que lo confundió estaba dirigida solo a equipos maduros con procesos y entornos eficientes y fluidos, podría decirse de manera mucho menos ambigua, por ejemplo, así:
Es posible que le guste más lo anterior y desee que sea así en todas partes, para todos, pero mire más de cerca esa parte del "desafío se plantea / permanezca ignorado / ajuste" y pregúntese cómo se puede implementar. Pregúntese cuánto tiempo puede tomar dependiendo del proyecto y el equipo. Si lleva una hora, ¿es eso aceptable? ¿Qué pasa si toma un día, o una semana, o ... un mes?
Verá, ese enfoque de desafío e ignorar hasta que se resuelva podría abrir una amplia puerta para el abuso si se presentara como una guía para cualquier proyecto. "Sí, sí, lo escuchamos, hagámoslo como dice la guía. Primero, complete este formulario de desafío y obtenga las aprobaciones de CEO / CFO / CTO; espere que esto tome una semana o dos. Después de eso, espere hasta que actualicemos nuestras comprobaciones de código ; eso puede tomar una o dos semanas más. Mientras tanto, asegúrese de que su código crítico de rendimiento vomite declaraciones de registro formateadas correctamente sobre cada movimiento de registro ".
No puedo leer las mentes de los autores de la guía, pero parece razonable suponer que querían evitar usarlo para justificar un desastre como se describió anteriormente. Desde esta perspectiva, es simplemente más seguro afirmar claramente que la guía no asume ningún cumplimiento; de esta manera, por torpe que sea, aún puede utilizarse para una amplia gama arbitraria de equipos y proyectos. Probablemente existe la expectativa de que una asignación tan amplia deja a los equipos más maduros y eficientes la oportunidad de reducirla razonablemente sin dañar la productividad del desarrollador.
Aplicado a su caso específico, escribir el documento de estilo de codificación para su equipo y fallar la revisión del código si el estilo no coincide: creo que debe calcular cuánto tiempo les tomará a los desarrolladores desafiar una regla en particular, ignorarla, resuelto y cambiarlo o recuperarlo según la resolución.
Si encuentra una manera de hacer que este proceso funcione sin introducir muchos obstáculos en su flujo de trabajo de desarrollo, entonces vale la pena considerar un enfoque de desafío / resolución formal y fácil de rastrear en lugar del caótico "violar si llora lo suficientemente fuerte".
Como nota al margen, me gustaría abordar lo que escribió en otro comentario : "Suponga que el estilo de codificación es ideal, y si ese no es el caso, etc."
Esta es una suposición peligrosa, de verdad. Me rompí la nariz (¡dos veces en un solo proyecto! Donde tenía una vasta experiencia e imaginé que lo sabía todo, imagínense) y le recomiendo encarecidamente que lo deje. Es más seguro asumir que la guía de estilo puede tener errores y hacer un esfuerzo para pensar qué hacer en caso de que se descubran dichos errores.
fuente
Permitir que las personas ignoren los estilos de codificación debido a preferencias personales es una mala idea.
La cita en su pregunta parece permitir que cualquier desarrollador simplemente diga "No voy a usar este estilo porque no me gusta".
Esto va en contra de todo, lo que hace que todos en el equipo hagan las mismas cosas para lograr consistencia y legibilidad.
Estoy de acuerdo en que un documento de estilo con tal declaración probablemente no tenga sentido.
Sin embargo, se recomienda cierta flexibilidad para cumplir con las pautas de estilo:
En conclusión: permita flexibilidad para cumplir con las pautas de estilo, a fin de satisfacer mejor las necesidades de su equipo, pero no por razones arbitrarias como preferencias personales.
fuente
El estilo de codificación y las guías de estilo existen para ayudar a que el código sea más legible. Y la legibilidad existe para ayudar con la complejidad.
Por lo tanto, en última instancia, si violar o no (lo llamaría adaptar) el estilo de codificación para satisfacer sus necesidades organizacionales se reduce a cuánto ayuda a hacer que las cosas sean comprensibles.
Recuerde, todo, y enfatizo, TODO, desde la programación OO hasta los paradigmas funcionales, hasta varios modelos de concurrencia, existe por la única razón de ayudar a las personas a lidiar con la complejidad.
fuente
Las organizaciones optan por tener estilos de codificación: no es necesario tenerlos en primer lugar.
Entonces, la cita que está leyendo aborda el problema más grande que veo con respecto a la codificación del "estilo" y los verdaderos "hackers" de las superestrellas: traes a un nuevo tipo a bordo y escribe un código que arrojará zombis y hará que esos viejos servidores tuyos griten rápidamente. .. pero su estilo de codificación es diferente de su "estilo organizativo aceptado". Se niega a cambiar y el proceso para lograr que todos se ajusten a su estilo particular llevará mucho tiempo y será costoso. ¿Ahora que?
La mayoría de los súper hackers que conozco vienen con egos tan grandes como sus habilidades, y quieren que la organización se adapte a ellos , no al revés. Entonces, tal vez su estándar de estilo de codificación debería ser más como una pauta de estilo de codificación para que pueda dejar que este hacker asesino siga escribiendo un código increíblemente rápido y sorprendente con cierta desviación de estilo, pero asegúrese de que todos los demás lo entiendan hasta que lleguen a su hacker épico estado, necesitan seguir las reglas (o incluso ayudar a limpiar después de él).
Por supuesto, esta es una pesadilla de gestión, pero la gestión de personas tecnológicas en general es un poco como pastorear gatos de todos modos. Entonces, la mayoría de las compañías tienen "pautas de estilo", no "estándares de estilo". Y las compilaciones no fallan y las revisiones de código no fallan automáticamente debido a violaciones de estilo en todas las empresas. Puede decidir el problema de administración que desea tener: permita que los hackers superestrella y tenga "pautas" o pierda las superestrellas y tenga un estilo de código más consistente.
fuente
Depende.
El lugar en el que estoy actualmente no tiene una guía de estilo, y no es gran cosa. Existen algunas ligeras variaciones entre los programadores, pero no tanto como para impactar la legibilidad, la capacidad de descubrimiento o la consistencia de manera significativa. Y tenemos un grupo lo suficientemente grande y una cultura lo suficientemente fuerte como para hacer cumplir que cualquier miembro nuevo del equipo se alineará (o de lo contrario).
En compañías anteriores, estábamos creciendo rápidamente y teníamos algunas personas que no estaban familiarizadas con el idioma y sus expresiones idiomáticas. En esa compañía, la afluencia de personas significaba que no había una cultura que exigiera una buena escritura. Y la gente nueva en el idioma significaba que había muchas cosas que ajustar. Los verificadores de estilo automatizados eran la forma más eficiente de hacer los ajustes, y una guía escrita real era la mejor manera de capacitar a las nuevas personas en nuestras expectativas.
Personalmente, no me interesan mucho las guías de estilo, y menos aún la aplicación de estilo automatizada. Si la persona ni siquiera puede aprender los modismos básicos, ¿por qué los está empleando como programador? Y si son un jugador de equipo tan malo que escribirán continuamente código con el que a otros les resulte difícil trabajar, ¿por qué los emplean en absoluto?
fuente
Esto es más una estratagema psicológica en lugar de una interpretación literal de la mejor manera de administrar los estilos de codificación. Hace que el equipo / empresa / gerente / líder sea menos autoritario. Me centraría más en las excepciones situacionales que en las personales. Independientemente del documento de codificación, el objetivo es facilitar la lectura. El código confuso debe abordarse y modificarse si se considera necesario. Hay muchas herramientas para ocuparte de las pequeñas cosas tediosas, así que úsalas.
Hay excepciones a cada regla. Déle a la gente "algo" de margen de maniobra. Cuanto menos estén todos involucrados en aceptar las reglas de estilo de codificación (Bienvenido, chico nuevo), más se sentirán inclinados a contraatacar. Muchas cosas son en blanco y negro, pero algunas están abiertas a interpretación.
El objetivo debe ser involucrar a todos en el espíritu de las pautas de codificación en lugar de luchar por cada pequeño detalle e interpretación.
Sí, llegará un momento en que el documento de estilo de codificación no tiene sentido para usar y se debe permitir que los desarrolladores profesionales y adultos sepan la diferencia.
fuente
Según sus ediciones, su objetivo es el objetivo correcto.
El uso de una guía de estilo ofrece muchos beneficios, pero los dos más importantes en mi opinión, son la legibilidad del código entre los miembros del equipo y la falta de compromisos "tontos" (como espacios en blanco solamente, o líneas adicionales y similares).
Para lograr su objetivo, la guía de estilo elegida (o creada) debe ser simple y fácil de cumplir. Intenta concentrarte realmente en lo que necesitas. A nadie le gusta tener que regresar y reescribir una gran muestra de código solo para hacer feliz a un personaje. Pero aún podría haber algún beneficio.
Asegúrese de que los miembros de su equipo aprueben la guía de estilo. Vas a sujetarlos, asegúrate de que estén de acuerdo o será una lucha eterna.
Asegúrese de que las violaciones de estilo sean una "advertencia" y no un "error", deje que un humano decida si la violación se encuentra con un error. La razón de esto es simple. Creo en un flujo de trabajo simple. Si en algún momento de la fase de "prueba" se produce un "fallo", no puede pasar a producción. Yo uso es como una seguridad. Incluso las correcciones urgentes tienen que pasar por una fase de prueba (aunque más corta). ¿Puede decir realmente que no va a impulsar esa corrección crítica de errores a la producción porque alguien usó un "en lugar de un '? ¿Qué pasa con el uso de un bucle for en lugar de cada uno? ¿Qué pasa si un bucle for tiene alguna mejora con respecto a cada uno? son decisiones que una máquina (linter) no puede tomar, así que asegúrese de tener un humano, juzgue la advertencia y no la máquina arroje una falla.
En cuanto a ignorar la guía de estilo, tendrá que juzgar eso caso por caso. Asegúrese de que la "desviación" tenga una razón real. Ellos vendrán El trabajo de los revisores es asegurarse de que haya una buena razón para la desviación y no una trivial.
fuente
Creo que la música de humor aquí es que si la sabiduría aceptada es que los estándares de codificación son incorrectos o incompletos, entonces es el menor de los dos males seguir si los desarrolladores están de acuerdo en general en lugar de pasar por el arduo proceso de obtener el documento modificado y revisado nuevamente.
También se debe tener en cuenta que las políticas de cumplimiento estándar del código de antaño no suelen ser la forma en que se hacen las cosas ahora.
En los viejos tiempos, simplemente te balanceabas sosteniendo el tomo al final del escritorio de los desarrolladores y citabas el capítulo y el versículo por qué su código violaba la sección 34.5.5767.
Ahora tenemos herramientas de análisis de código estático y documentación automática que eliminan gran parte del trabajo pesado de los estándares de código.
Si falla todo esto, aún puede devolverlo al desarrollador, subirlo a una revisión de código o simplemente cambiarlo usted mismo si así lo desea.
fuente
Su pregunta se centra en conciliar las dos citas. Creo que lo que Treecoder escribió responde a su pregunta en general. Representa su principio rector en las pautas de estilo de escritura.
Más específicamente, dado que usted es responsable de establecer las pautas de estilo de codificación (esta es mi suposición ya que usted es el redactor de documentos), puede decidir qué es opcional o no, y en qué medida permitirá flexibilidad en el estilo personal de su equipo. Recibirá comentarios cuando sea necesario. Pero una vez que las pautas estén en su lugar, quédese con ellas.
Para que pueda conciliar las dos contradicciones aparentes como esta:
Piense en la primera cita dirigida a usted como el tomador de decisiones de estilo, antes de que se complete el documento de pautas. Si un determinado estándar de estilo no funciona para su equipo, entonces esto cuenta como una "fuerte objeción personal" y sus pautas lo reflejarán.
Piense en la segunda cita dirigida a su equipo, después de completar el documento. Una vez que haya establecido las pautas para el equipo y el documento esté escrito, es importante que todos los desarrolladores de su equipo cumplan con las pautas de estilo.
fuente
No importa demasiado qué estilo de codificación tengan las personas, siempre que tengan un estilo de codificación. Si una empresa insiste en un estilo de codificación, pisan fuertemente a los dedos del 49% de sus desarrolladores.
El problema es que a una gran cantidad de desarrolladores no les importa adaptar su estilo de codificación a algún estándar prevaleciente en una empresa, pero les importa mucho que les digan aquellos que son mejores (o simplemente se preocupan más) por la política de la empresa.
Eso significa que crear un estándar de estilo de codificación puede ser una gran pérdida de tiempo, una fuente de argumentos interminables, la causa de un resentimiento infinito y, en general, una gran pérdida de tiempo y energía.
fuente
He lidiado con pautas de estilo de código durante años, como lo han hecho muchos otros en este foro. Esto incluye las dos guías de estilo de lucha que considero aborrecidas, y tratar de alentar a otros a usar guías de estilo para controlar su estilo para que pueda ser más legible en su conjunto.
La corporación se beneficia de un estándar de codificación común. Hay muchas cosas importantes a tener en cuenta al desarrollar software para una empresa, como cómo entrenaremos a los nuevos desarrolladores para que recojan el código de la generación anterior. Cuando escribes código, no siempre estás pensando en esto. De hecho, muchos codificadores eligen ni siquiera considerar cómo otros podrían querer acercarse al código 5 o 10 años después de que se hayan ido. Una guía de estilo de codificación es una forma en que una empresa puede enfocarse en estos objetivos de 5 y 10 años, facilitando a los desarrolladores trabajar en el esquema más amplio de las cosas.
Por otro lado, las guías de estilo de codificación son notoriamente imperfectas, porque no es posible desarrollar un estilo de codificación perfecto y escribirlo. De hecho, comienzas a toparte con casos divertidos en los que las pruebas matemáticas comienzan a fallar si intentas hacerlo perfecto. Entonces sabemos que las guías de estilo de codificación son imperfectas. Es posible que no se centren perfectamente en lo que necesitamos dentro de 5 a 10 años.
Si "impusiéramos" un estilo de codificación, estaríamos sacrificando valor ahora por valor más adelante. Esto se llamaría "inversión" si pudiéramos estar seguros de que obtendríamos un retorno de nuestros esfuerzos, pero cualquier desarrollador que haya trabajado con una guía de estilo de codificación mal escrita puede dar fe de que esas ganancias de "legibilidad" se pagan caro distrayendo a los desarrolladores lejos de su código. En mi experiencia, solo hay un número muy pequeño de casos en los que los estilos de codificación forzada tienen mérito, generalmente en software para clientes exclusivamente glaciales, ¡donde el software puede usarse durante 30 o 40 años!
En cambio, me parece más efectivo tratar una guía de estilo de codificación como un manifiesto: "Esto es lo que creemos que es el mejor estilo de codificación para nuestro grupo". Es un montón de pensamientos fluidos documentados en palabras. La palabra "creer" es importante: si las creencias cambian, las guías de estilo de codificación deberían cambiar con ella.
Aquí es donde entra tu cita de "objeciones personales fuertes". En lo que yo llamaría un mundo "perfecto", escribes el código que crees que es mejor y vives con las consecuencias. A menudo nos gusta pasar por alto las consecuencias "suaves" cuando estamos programando, pero en este caso son importantes. No tengo ningún problema con que escribas en tu propio estilo, si no te importa que nunca te dé nada importante y duradero para desarrollar.
Piense en todo el sistema como un campo de golf. El estilo de codificación allana el camino fácil por la calle. Si cumple con el estándar de codificación, nos aseguraremos de que la vida sea lo más fácil posible. Cuanto más avance en el camino, utilizando sus propios estándares de codificación, más tendrá que demostrar su valor en el equipo.
Si vengo el lunes por la mañana, para descubrir que has pasado todo el fin de semana resolviendo un problema por el que nos hemos estado preocupando durante un año, y lo hiciste en tu propio estándar de codificación "especial", no voy a decirte que arreglalo. Te voy a decir que te duches. Si su estándar de codificación "especial" es excepcionalmente "especial", incluso podría sugerirle a un desarrollador de nivel de entrada que "revise" el código para difundir el conocimiento de cómo funciona su código y mencione que si algo parece difícil de leer, él / ella debería poner en orden. Ese fin de semana, usted proporcionó suficiente valor a la compañía para que valga la pena ni siquiera mencionar las graves violaciones de los estándares de codificación que cometió.
Hay, por supuesto, fuera de límites en esta metáfora de golf. Si le pido que haga una tarea de clasificación y archivo, tal vez agregando nuevos campos a algún formulario, y decide aprovechar la oportunidad para refactorizar todo el código de llenado de formularios para que se adapte a su estilo particular, usando un montón de caracteres sombreados como definir macros y alguna técnica de metaprogramación de plantilla horrible que acabas de aprender del intercambio de pila, se te pedirá que regreses y la arregles. Elegiste actuar, esas son las consecuencias.
( Descargo de responsabilidad: he escrito totalmente esta implementación
is_base_ofpara resolver una tarea de baja categoría, y me gané todo el infierno que obtuve de los desarrolladores senior. Digo que valió la pena. Todavía recibo una alegre burbuja de risa cada vez que mira cómo ese patrón se une a 7 partes no relacionadas de la especificación de C ++ para hacer algo increíble. ¡Tómalo, desarrolladores senior! ¡Eso es lo que obtienes por prohibirboosten este proyecto en particular! )fuente
Best parece usar el formateador de código automatizado que es una característica incorporada de casi cualquier IDE de descendencia y debería existir para casi cualquier lenguaje de programación más o menos extendido. Esto elimina silenciosamente mucho trabajo innecesario y mucha fricción durante las revisiones de código.
Es completamente razonable exigir a todos los desarrolladores que desarrollen un hábito para aplicar el formateador a la sección recién creada del código.
Lo peor que puede hacer es exigir un estilo de codificación personalizado que el formateador de código existente no admite.
En casos relativamente raros, alguna sección puede formatearse de manera diferente, si el formateador lo hace realmente mal, pero generalmente es mejor ajustar el formateador para que todos formateen mejor.
Puede haber algunas reglas útiles que el formateador no puede admitir (cómo nombrar variables, por ejemplo), pero si solo estas permanecen, son relativamente fáciles de seguir.
fuente
Solución real (no solo filosofía)
Permita que los comentarios de código anulen el linting y compile listas de esos comentarios si lo desea (como se hace con los comentarios de todo a menudo)
Ofrezca a sus desarrolladores la capacidad de trabajar fuera de la convención explícitamente y con razón, y durante las revisiones de código por parte de humanos, se puede analizar según sea necesario.
fuente