¿Existe una manera de admitir diferentes estilos de codificación en un equipo de desarrollo?

No, necesitarás hacer un estándar. Si tiene un miembro del equipo B, cambie (ya sea con una herramienta IDE automática o manualmente) un montón de código que escribió el miembro del equipo A, se confirmará y se mostrará como un cambio.

Esto es algo que casi todos los equipos enfrentan y los estándares son "forzados" por esta misma razón. Le sugiero que siga las normas de las autoridades lingüísticas como una línea de base y las adopte para adaptarse a su equipo.

Tener un estilo de codificación coherente también ayudará a mantener el proyecto y reducirá la barrera de entrada para las nuevas personas que trabajan en el código.

No, deberá definir un estándar de codificación (preferiblemente uno que ya existe) y que sus desarrolladores se adhieran a él. Ser un programador profesional significa que puede adaptarse a cualquier estándar de codificación que se utilice en el proyecto en el que está trabajando.

SÍ, puede funcionar siempre y cuando los estilos sean sensibles y la gente no cambie el código de otras personas para que coincida con sus preferencias y / o mezcle estilos en un solo archivo de código.
No es lo ideal, pero no es diferente de heredar el código antiguo creado a un "estándar" diferente del suyo y tener que integrarlo con su base de código.
Así que si tienes que hacerlo, algunas pautas:

• sin cambiar el código de estilo diferente para que coincida con sus preferencias, cuesta tiempo e introduce errores
• permanece consistente dentro de cualquier archivo único. Entonces, si el estilo A se usó para escribirlo inicialmente, todos usarán el estilo A cuando lo modifiquen
• cree un estándar común para su interfaz pública, por lo que para todo lo que está expuesto al exterior (y sí, otros subcomponentes de un sistema son el exterior).

La respuesta corta es No.

Mientras que las opiniones se deben valorar en el trabajo, especialmente en un trabajo basado en el conocimiento como el Desarrollo de software, los desarrolladores deben darse cuenta de que una opinión es solo una opinión y que están ahí para escribir software y no discutir sobre qué línea de sangría es mejor.

El objetivo de un documento de estándares debe ser hacer cumplir / sugerir un conjunto de estándares / convenciones de codificación comunes que aborden

1. Elementos de diseño como tabulación, sangría, uso de {, (,
2. Nombre de variable, objeto y función, es decir, CamelCase, notación húngara
3. Manejo de excepciones cómo / cuándo / dónde debe realizarse
4. Comentarios del código. ¿Siempre hace referencia a un documento de diseño, un número de error, etc.?

Los documentos de estándares ayudan a garantizar que el código sea fácil de leer, mantener y coherente en sus convenciones.

Esto tiene un valor incalculable al revisar el código antes de los registros, depurar el código de otra persona o modificar el código varios años después de que el desarrollador original haya abandonado la empresa.

Normalmente, al crear un documento de estándares de codificación reviso los estándares de la industria para el lenguaje que estoy usando (C, C #, SQL), uso los estándares más apropiados, circulo a los desarrolladores más importantes / influyentes para comentarios, incorpore los comentarios donde apropiado y luego liberar el documento.

En teoría, es posible reformatear automáticamente el código antes de comprometerse con su sistema de control de versiones.

Sin embargo , hay un gran problema: las herramientas automáticas de formato de código no son 100% confiables. Por lo tanto, realmente podría introducir problemas en su código con este sistema. En mi mente, eso mata la idea. ¡Siempre es más importante tener un código funcional que un código con el estilo correcto!

Si el proyecto está dividido en compartimientos, y la mayoría de las partes del código tienden a ser "propiedad" de programadores individuales, entonces puede estar bien dejar que usen sus propios estilos (dentro de lo razonable). Sin embargo, si varias personas trabajan con frecuencia en el mismo código, probablemente sea necesario imponer un estilo.

Aquí hay una discusión similar sobre Desbordamiento de pila .

El código de reformateo unidireccional puede ser una solución viable si:

1. Encuentre un autoformateador que realmente funcione para la convención que desea implementar y su lenguaje de programación.
2. Puede hacerlo antes de comprometerse para que el cambio de formato no se muestre en los registros de cambios mezclados con los cambios funcionales reales y no se distinga de ellos.
3. Logre que su equipo acuerde qué convención se debe aplicar (porque, en general, no hay "vuelta atrás" en el check-out a la preferencia personal de un desarrollador, al menos no que yo sepa).

Ninguno de estos es realmente fácil de hacer en muchos casos, ¡así que considera elegir tus batallas aquí! He visto a los equipos hacer esto con éxito para un proyecto C # / .NET donde el cambio de formato ya ocurrió en la PC del desarrollador, por lo que es posible en algunas circunstancias.

Absolutamente puedes. Se trata de no sudar las cosas pequeñas.

El único estándar que importa es "mantener los cambios del mismo estilo que el código existente". Mientras pueda adaptarse a un estilo de codificación que no sea el preferido, puede trabajar con cualquier estilo de codificación.

Entonces, ¿cuál es el problema de trabajar en 3 estilos diferentes dentro de la misma empresa? Sus desarrolladores deben entender esto, ya que escribir código de la manera que les gusta es encontrarlo para su código, pero una vez que realizan cambios en un archivo diferente que usa un estilo diferente, tienen para mantener ese estilo (o realmente se verá mal). No se permite reformatear (o simplemente se reformatearán continuamente y las scm diffs serán inútiles) (y si lo hace, entonces debería emplearse un formato automático).

Es probable que, una vez que se pongan en marcha con esto, lleguen a un consenso acerca de qué estilo usar o el estilo se desviará en su mayor parte. Si van a ser infantiles al respecto y reformatearán el código de cada uno de los demás todo el tiempo, entonces será el momento de descargar un estándar de Internet y exigir que lo usen. Podrías querer hacer esto de todos modos, solo agitarlo en sus caras como una tarjeta de "jugar bien o de lo contrario".