¿Es una buena idea imponer el mismo formato de código para todos los desarrolladores?

88

Estamos considerando imponer un formato de código estándar único en nuestro proyecto (formato automático con acciones de guardar en Eclipse). La razón es que actualmente hay una gran diferencia en los formatos de código utilizados por varios (> 10) desarrolladores, lo que dificulta que un desarrollador trabaje en el código de otro desarrollador. El mismo archivo Java a veces usa 3 formatos diferentes.

Entonces, creo que la ventaja es clara (legibilidad => productividad), pero ¿sería una buena idea imponer esto? Y si no, ¿por qué?

ACTUALIZACIÓN
Todos usamos Eclipse y todos conocen el plan. Ya hay un formato de código utilizado por la mayoría, pero no se aplica, ya que algunos prefieren mantener su propio formato de código. Debido a las razones anteriores, algunos preferirían hacerla cumplir.

Stijn Geukens
fuente
2
¿Todos sus desarrolladores usan Eclipse? ¿les hablaste sobre este plan? Sin saber esto, su pregunta es difícil de responder, uno tendría que adivinar demasiado
mosquito
99
¿ Realmente hace que sea más difícil para un desarrollador trabajar en el código de otro, o los desarrolladores simplemente están siendo alérgicos a leer códigos ligeramente diferentes?
Joris Timmermans
27
Cuando utilice un sistema de control de código Scource (como svn), asegúrese de que los cambios en el formato del código se realicen por separado de los cambios semánticos; de lo contrario, será difícil encontrar esos cambios semánticos.
Martin Schröder
44
No estoy de acuerdo con Martin aquí, bueno más o menos. Mi regla general es que si haces un cambio lógico / semántico, entonces puedes cambiar el formato de las líneas que cambiaste, de lo contrario no puedes cambiar el formato de las líneas solo porque te apetezca. No obstruya su registro de control de versiones con pequeños cambios de formateo.
Benedict
3
Por otro lado: si todos usan el mismo formato, solo el primer commit para reformatear todo estará obstruido con él. Todo lo demás solo tocará los cambios locales realizados, lo cual es aceptable en mi opinión.
Jeroen Vannevel

Respuestas:

107

Actualmente trabajo en un lugar donde se aplica un formato de código estándar y el código se formatea automáticamente al guardar el archivo, tal como está a punto de hacer. Como nuevo miembro de la compañía, descubrí que las reglas de formato comunes me daban una sensación cálida y confusa de que "estos tipos saben lo que están haciendo", por lo que no podría estar más feliz. ;) Como nota al margen relacionada, con las reglas de formato comunes también aplicamos ciertas configuraciones de advertencia del compilador bastante estrictas en Eclipse, con la mayoría de ellas configuradas en Error, muchas configuradas en Advertencia y casi ninguna configurada en Ignorar.

Diría que hay dos razones principales para imponer un formato de código único en un proyecto. Primero tiene que ver con el control de versiones: con todos formateando el código de manera idéntica, se garantiza que todos los cambios en los archivos serán significativos. No más simplemente agregando o eliminando un espacio aquí o allá, y mucho menos formateando un archivo completo como un "efecto secundario" de cambiar solo una o dos líneas.

La segunda razón es que de alguna manera saca los egos de los programadores de la ecuación. Con todo el mundo formateando su código de la misma manera, ya no se puede saber tan fácilmente quién ha escrito qué. El código se vuelve más anónimo y de propiedad común, por lo que nadie necesita sentirse incómodo por cambiar el código de "alguien más".

Siendo esas las razones principales, también hay otras. Me resulta reconfortante no tener que preocuparme por pensar en el formato del código, ya que Eclipse lo hará por mí automáticamente cuando guarde. Es libre de preocupaciones, como escribir documentos con LaTeX: está formateado después y no tiene que preocuparse por eso mientras escribe. También he trabajado en proyectos donde todos han tenido sus propios estilos. Luego, debe pensar en cuestiones estúpidas y sin sentido, como si está bien modificar el código de otra persona en su propio estilo, o si debe tratar de imitar su estilo.

El único argumento en contra de la configuración de formato de código común que se me ocurre para su caso es que aparentemente es un proyecto ya en curso, por lo que causará muchos cambios innecesarios en todos los archivos, lo que desordenará el historial real de los archivos. El mejor de los casos es si puede comenzar a aplicar la configuración desde el comienzo de un proyecto.

Cero uno
fuente
20
+100 en sacar los egos de los programadores (y la propiedad) de la ecuación. El "reclamo" de los programadores a partes del código no contribuye a la productividad porque impide el intercambio de conocimientos y significa que hay una señal dado que no todos los programadores podrían trabajar en el mismo código.
Marco
Fue difícil decidir qué respuesta aceptar, pero encontré que esta era la mejor discutida y también la mejor para abordar la pregunta real.
Stijn Geukens
"significa que hay una señal dado que no todos los programadores podrían trabajar en el mismo código": Bueno, pero esto es realmente algo que puede querer tener: siempre y cuando no esté lo suficientemente familiarizado con un código, debe No trabajar en él / modificarlo. Demasiada propiedad de código compartido puede hacer que todos trabajen en toda la base de código y nadie realmente domine ninguna parte de él.
Giorgio
Tendría mucho más tiempo para este tipo de cosas si el código se formateara automáticamente a mi estilo durante la carga. Cuando Roslyn aterriza para C #, espero ver todo el trabajo de carga, guardado, versionado, etc. en el AST en lugar del texto.
Mark Rendle
Advertencias y errores más estrictos son algo bueno.
Christophe Roussy
37

Todo desarrollador de software profesional preferirá adoptar un estándar (bueno) en lugar de entrar en guerras evangélicas por el estilo, por las mismas razones que usted ha descrito.

Muchos desarrolladores de software libran guerras evangélicas ......

Dependiendo de su posición dentro del equipo y la dinámica del equipo, puede decidir que no es posible ganar la guerra. En este caso, puede ser mejor no comenzar ...

Mattnz
fuente
Tx, sé exactamente lo que quieres decir
Stijn Geukens
15
No es profesional librar guerras sobre el formato de código. Un desarrollador de software profesional hará las cosas igual de bien sin importar si su código dice " if( foo )" o " if (foo)". Si realmente necesita vender este tipo de cambio a alguien, debe apelar al hecho de que son profesionales. No pueden responder o parecerán anal-retentivos. Si alguien lo hace de todos modos, bueno, espero que por tu bien encuentren un nuevo trabajo pronto.
ZeroOne
77
Un desarrollador profesional también escribiría un código legible y podría leer el código de otros desarrolladores profesionales con bastante facilidad, obviando la necesidad de un estándar extenso en primer lugar. Me preocuparía que aquí "el estándar" sea una mala solución para el problema incorrecto (no se arreglan los desarrolladores descuidados con un estándar de codificación).
Joris Timmermans
2
La mejor manera de tratar de esquivar la mayoría de estas guerras santas es aceptar los valores predeterminados del idioma siempre que sea posible. Sí, eso significa que su estilo de codificación variará según los idiomas (por ejemplo, el código C # tendrá {'s en líneas separadas, Java los tendrá en la línea anterior, y lo que PascalCased o camelCased variará); pero cada fuente de idiomas individuales se verá "normal" cuando traiga nuevos desarrolladores al proyecto.
Dan Neely
1
@ruakh Mire las muestras de código MSDN C #, mire cómo Visual Studio reformatea C # de manera predeterminada: {está en su propia línea. Repita el ejercicio para Java en la documentación de Oracle y los valores predeterminados de Eclipse al reformatear el código: {está en la línea de arriba.
Dan Neely
30

Sí, es bueno tener estilos de formato de código único para todos los desarrolladores.

Diseñe los formatos de estilo de código e impórtelos a todos los desarrolladores eclipse.

Esto ayudará cuando tengamos mergingcódigo para el sistema de 'Control de versiones'.

NPKR
fuente
55
+1 por mencionar las herramientas de fusión y diferenciación. Es un verdadero dolor tratar de detectar diferencias entre dos versiones de una base de código cuando el formato no es consistente entre los desarrolladores.
pgras
1
+1, secundo el argumento del sistema de control de versiones. (pero se debe principalmente a las reglas de sangría. Cosas como las convenciones de nomenclatura no tienen tanto impacto)
BiAiB
Las convenciones de nomenclatura ayudan cuando necesita averiguar cómo se llama un método que sabe que existe en una clase.
Dan Neely
1
@Giorgio De hecho, hay desarrolladores que hacen eso. Mientras se mezcla con otros cambios también (por ejemplo, correcciones de errores críticos). Se envían algunas cosas para probarnos ...
Donal Fellows
1
@Donal Fellows: Tienes razón. Sigo el principio de que cada carácter que escriba en un archivo fuente es (1) un error potencial (2) introduce un cambio que hace que el código sea difícil de reconocer después. Entonces, en mi opinión, cada cambio debe ser lo más pequeño posible. Pero sí, hay desarrolladores que cambian el código sin pensar demasiado. Me pregunto si un reformateo automático del código puede resolver el problema. Prefiero estar a favor de la propiedad del código (ver, por ejemplo, el punto 7 en paulgraham.com/head.html ).
Giorgio
16

¿Qué estás tratando de ganar, qué tan anal retentivo vas a estar haciendo cumplir (y en el nivel de detalle que se establecerán tus "reglas"), vas a tratar de hacerlo cumplir en el código escrito en diferentes idiomas, ¿Vas a intentar aplicarlo retroactivamente en el código existente?

  1. Una apariencia común para codificar puede ayudar a que el código sea más legible, pero también puede empeorar las cosas si es incorrecto. La notación _hUngarian_lpfstr es un buen ejemplo :)
  2. He visto "estándares de código" que imponen el número de espacios en blanco en los bloques de comentarios, el orden alfabético de los nombres de los métodos y otras tonterías. No hagas eso.
  3. Diferentes idiomas tienen diferentes estándares a los que las personas están acostumbradas y tienen experiencia en su uso. Algunos incluso exigen estos estándares (piense que Python, Cobol, Visual Studio imponen automáticamente convenciones de refuerzo de estilo C ++, mientras que Java usa el estilo C por convención, etc., etc.).
  4. nunca cambie el código existente por cambiarlo, solo está introduciendo nuevos problemas de esa manera. Y eso significa secciones de código, así como archivos fuente completos. Así que no vuelvas a formatear el código existente cuando alguien cambie una sola línea en un archivo de 1000 líneas.
  5. los programadores experimentados pueden ser mucho más productivos si no tienen que pensar la mitad del tiempo si lo que están escribiendo "se verá bien" para el sistema de aprobación automática o el revisor. También tendrán la costumbre de escribir código limpio simplemente porque eso es lo que funciona, incluso si hay pequeñas diferencias entre sus estilos naturales.



Entonces, si bien existen buenas razones para imponer un estilo y un estándar específicos, existen buenas razones para no hacerlo (también) estrictamente.

jwenting
fuente
1
1-2-3: es Java y el formato del código es el de Sun; es solo formateo, así que no está ordenando métodos o nombres de variables; 4-5: bueno, la idea sería formatear automáticamente al guardar (acciones de guardar de Eclipse) para que no haya trabajo adicional (ni siquiera necesita pensar en el formato mientras se codifica) pero, por supuesto, los archivos existentes también se formatearán (el primera vez).
Stijn Geukens
1
+1 para KISS. @Stijn ¿Por qué reformatear el código antiguo? Simplemente golpéelo cuando necesite modificarlo.
Erik Reppen
3
En realidad, estamos planeando algunas refactorizaciones importantes y reformatearíamos todo el código en ese momento, ya que la fusión será casi imposible de todos modos debido a la refactorización. Si solo reformateamos el cambio, aún enfrentaremos problemas de fusión debido al cambio de formato dentro de un año.
Stijn Geukens
44
Generalmente estoy de acuerdo con @StijnGeukens; no solo por razones de fusión, sino porque cualquier limpieza de formato a gran escala dificultará el siguiente historial de cambios en una herramienta de culpa. Si todos sus cambios de ruido están en una sola ubicación, siempre puede establecer la culpa para comenzar antes de ese punto inicialmente y luego hacer una segunda ronda deteniéndose antes si necesita ver un historial más antiguo.
Dan Neely
2
olvidó otra razón Dan: los cambios de formato a gran escala pueden introducir fácilmente nuevos errores en lugares inesperados.
Jwent
11

Sí, la coherencia es una buena idea, por razones que otros han mencionado .

Solo quería agregar un par de puntos que no se han utilizado en otros lugares:

  • Oracle ha publicado un conjunto de convenciones para Java, que son el estándar de facto.
    • Usarlos debería ayudarlo a evitar discusiones sobre qué estilo seguir.
    • Muchas bibliotecas públicas y proyectos de código abierto tienden a usar estas convenciones, por lo que cuando necesite verlas, el formato debe ser familiar.
    • El formateador de Eclipse tiene reglas integradas para que coincidan con estas convenciones, lo que también debería ayudar.
  • Es posible que desee considerar la creación de un enlace en la configuración de control de origen para que el código se formatee automáticamente antes de que entre en la rama principal.
    • Puede evitar batallas con programadores especialmente obstinados que se niegan a seguir el estándar. Incluso pueden usar su propio formato mientras trabajan, lo que se estandarizará más adelante.
    • Si termina utilizando una configuración de formato personalizada (por ejemplo, mucha gente ignora la convención de "máximo 80 caracteres por línea"), solo tiene que hacer cambios en un lugar.
vaughandroid
fuente
9

Estaba en un equipo que usaba el complemento Checkstyle . En lugar de utilizar las funciones listas para usar, formamos un pequeño comité de desarrolladores interesados. Debatimos sobre lo que parecía faltar, lo que parecía excesivo, y resolvimos las cosas. Todos aprendimos algo en el proceso y fortalecimos esos músculos desarrolladores.

(Ejemplos de nuestras decisiones: 72 caracteres de ancho es demasiado pequeño, pero 120 fue mejor; es mejor usar _ALLCAPS para finales estáticos; forzar la salida única de una función es una buena idea).

Cuando tuvimos revisiones de código, una de las primeras preguntas fue: "¿Lo has pasado por Checkstyle?" El cumplimiento de los estándares de codificación fue en gran medida automatizado, y desvió la atención de que el revisor fuera exigente. Fue maravillosamente fácil hacer que Checkstyle resalte la firma de un método, haga clic derecho y cambie una variable a final. También podría arreglar las hendiduras y llaves para que el código de todos tuviera una apariencia similar. ¿Falta un Javadoc para una función pública? Checkstyle marcará la función.

(Eliminar el olor del código es más importante que el formato consistente. Esto es un beneficio de las herramientas automatizadas).

Colocaría herramientas automatizadas como Checkstyle menos que imponiendo el mismo formato y más para fomentar una apariencia similar. Y cuando está criando gatos, una herramienta automatizada puede ayudar a mejorar las habilidades y reducir el olor del código sin dañar los egos frágiles.

rajah9
fuente
55
¿Único punto de salida? Hay ciertos principios de estilo con los que realmente no estoy de acuerdo. (Si las salidas múltiples son un problema, la función / método es demasiado larga en primer lugar ...)
Donal Fellows
@DonalFellows, Checkstyle nos dio un punto de referencia desde el cual podríamos cambiar hacia las preferencias del comité. Hubo muchas exclamaciones de la naturaleza: "¡No veo por qué pusieron este estándar!" Mientras que el OP preguntaba por un formato consistente, creo que la herramienta automatizada ofrece mucho más sin dolor adicional.
rajah9
6

Si va a apegarse al mismo IDE e incorporar algunas herramientas de formateo, es una buena idea porque no requiere demasiado esfuerzo. Mantenga las reglas simples con un enfoque en la legibilidad y no en la retención anal . Esa debería ser la vara de medir.

Si bien una bola de lodo formada consistentemente es mejor que una simple bola de lodo, sería mejor dedicar su tiempo a limpiarla en lugar de ser demasiado exigente con respecto a dónde van los soportes. No se convierta en el gerente con cabeza de alfiler que siente que está haciendo su trabajo contando los espacios de sangría durante una revisión del código y asegurándose de que las nuevas portadas estén en los informes de TPS .

Las preferencias personales son solo eso y rara vez mejoran la producción: https://stackoverflow.com/questions/249432/whats-the-reasoning-behind-the-different-brace-forms

Si es así, supéralo y haz algo.

JeffO
fuente
6

Recomiendo encarecidamente que los humanos apliquen el formato del código y que las infracciones menores se pasen por alto o se modifiquen. Las razones para esto son, brevemente,

  1. La máquina se equivoca en el peor momento posible, y generalmente cuando está utilizando una nueva función de idioma. ¿Cómo manejará los cierres en Java, etc.? Jalopy tiene problemas con enumeraciones con funciones miembro.
  2. Creo que es una carga muy razonable para el programador producir código para la compañía que se parece al código de la compañía. Me ha resultado útil mencionar que así es como se formatea el código "aquí", no cómo se debe formatear todo el código en todas partes. Su compañía anterior puede haber elegido un camino diferente, y eso está bien. No muy diferente del lenguaje vernáculo, hay expresiones idiomáticas específicas de su cultura de código que desea resaltar.
  3. La aplicación de la sintaxis del código se realiza mejor con revisiones de código:
    1. Si el formateo es importante, entonces su organización debe hacer revisiones de código. Esto es de gran beneficio.
    2. Si se rompe una regla de formateo, un humano puede verla y juzgar mejor que una máquina si la intención se transmite de manera más limpia. Esto es muy raro, pero ocurre ocasionalmente.

Con respecto a "legibilidad => productividad", la estructura del código (como las clases y funciones de responsabilidad única) lo comprará mucho más rápido que el formateo del código. El formato de código puede ser de ayuda, pero diferentes mentes analizan las declaraciones de manera diferente: no todos serán "más productivos". Me gustaría duplicar la estructura del código sobre el formato porque eso es algo que también lo llevará a hacer revisiones de código y hacer que el equipo piense en cómo funciona el programa, no en cómo se ve un solo bucle.

No soy un gran admirador de Domain Driven Design, pero es un modelo reciente que tiene una idea MUY bien definida de cómo se debe estructurar el código y las convenciones de formato de código fluyen naturalmente de un programa estructurado de Domain Driven Design. De nuevo ... No me gusta DDD, pero es un gran ejemplo porque está muy bien definido.

Supongo que el tema de esta respuesta es: hacer revisiones de código y dejar que el formato fluya desde la cultura y fuera del proceso de revisión.

Sam
fuente
Tx, no es un mal punto de vista esto. Pero, de nuevo, es un trabajo adicional si durante cada revisión el revisor también debe verificar el formato.
Stijn Geukens
3
Es un clic extra para llamar a una línea en algo como Fisheye como "sangría inconsistente" o "abrazadera abierta en línea por sí misma", así que sí, es más que cero esfuerzo. Sin embargo, si esto extiende las revisiones de código en más de literalmente 1 minuto, hay un gran problema. Después de una semana de que el equipo revise su propio código, todos deberían ser muy rápidos en notar el código "incorrecto" y retocarlo.
Sam
4

En general, suponiendo que contrate desarrolladores razonables, es una mala idea imponer un formato de código universal. Sin embargo, es una buena idea adoptar pautas de código .

Nunca he visto un conjunto de reglas de formato de código que optimice la legibilidad en todos los casos. Del mismo modo, no hay reglas gramaticales 100% aplicables en inglés: nuestros cerebros simplemente no están conectados de esa manera. Así que use pautas, pero dé a los desarrolladores la libertad de anularlas como mejor les parezca.

Dicho esto, una regla más difícil de "seguir la convención de código que ya existe en el archivo / proyecto" es buena.

Pero tenga en cuenta que el formato contribuye mucho menos a la legibilidad que simplemente qué tan lógicamente está organizado el código. ¡He visto muchos códigos de espagueti ilegibles con un formato perfecto!

Keredson
fuente
2

No creo que haya una respuesta simple a esto. No es una pregunta de sí o no. Si bien creo que el estilo y las convenciones de nomenclatura son importantes hasta cierto punto, también es bastante fácil perder demasiado tiempo pensando en ello. Es mejor responder con el ejemplo.

En un proyecto en particular en el que estaba, no había convenciones en absoluto. Cada desarrollador hizo las cosas a su manera. Debido a la relativa inexperiencia de este equipo, pasar de una clase a otra fue realmente discordante. El estilo era menos problemático que el problema de las convenciones de nomenclatura. Un desarrollador haría referencia a los elementos de la interfaz de usuario con una horrible notación húngara (una práctica tonta en la era de los IDE modernos), uno nombraría a los miembros privados de una manera, otro los nombraría de manera diferente. Nunca supiste lo que estabas mirando.

En el extremo opuesto, un equipo usó StyleCop (este fue un proyecto .Net) como parte de su proceso de construcción. Lo que es peor, es que también usaron la mayoría de las reglas predeterminadas. Por lo tanto, haría algo totalmente normal en términos de espacio entre líneas o colocación de llaves, y la construcción vomitaría por eso. Se desperdició mucho tiempo simplemente agregando espacios y líneas a las cosas, y todos, incluidos los tipos que insistieron en usar StyleCop, terminaron haciéndolo casi en cada confirmación. Fue una enorme pérdida de tiempo y dinero.

Entonces, lo que quiero decir aquí es que ser inflexible no es la respuesta, pero estar en el Salvaje Oeste tampoco lo es. La verdadera respuesta es encontrar el lugar que tenga más sentido, que en mi opinión es no tener herramientas automatizadas que controlen cosas, pero tampoco arrojar convenciones al viento.

Jeff Putz
fuente
2

Mi argumento principal contra el estilo de codificación común es que un programador experimentado se utiliza para leer su propio estilo. Puede entrenar la mano para escribir un estilo específico, pero es casi imposible entrenar el ojo para comprender un estilo que odia. Un programador escribe un fragmento de código una vez y luego lo lee una y otra vez durante el desarrollo y la depuración. Si cada vez que lee su propio código le cuesta entenderlo, ya que se vio obligado a escribirlo en un estilo MALO, será muy infeliz y menos productivo. Esto es de mi experiencia.

No estoy muy familiarizado con Eclipse, pero el formato automático en guardar suena como una idea horrible. Un desarrollador debe tener un control completo sobre su código, independientemente de si el estilo de codificación se impone o no. La operación 'guardar' no debe cambiar un solo carácter sin el consentimiento explícito del usuario.

Si su empresa vende código fuente, el estilo de codificación es más importante, pero si vende código compilado, es mucho menos relevante.

Esperar que el estilo de codificación haga que el codificador original sea menos distinguible y evite las guerras del ego es una mierda en el mejor de los casos y una estupidez en el peor de los casos. Los grandes programadores siempre producirán código elegante independientemente del estilo.

También estoy firmemente a favor de que cada desarrollador posea unidades de código específicas y no permita que todos toquen cada pieza de código libremente. Desarrollar unidades enteras en el código y ser responsable de ellas permite que el desarrollador se enorgullezca de su trabajo y evita que desarrolle un código malo sabiendo que los errores volverán a cazarlo.

Finalmente, cualquiera que tenga un estilo de codificación profesional siempre asume que se seleccionará su propio estilo de codificación y todos los demás lo seguirán. Imagine que el estilo de codificación que menos le gusta de todos sus co-desarrolladores seleccionados como estándar. ¿Sigues a favor de imponer un estilo de codificación?

Gur
fuente
2

Un formato para gobernarlos a todos ... ¿es realmente óptimo?

Es como conducir el auto de otra persona ...

Claro que puede subir y conducir cualquier automóvil, pero estará más seguro, más cómodo y será menos probable que se estrelle si se toma el tiempo de ajustar el asiento, el volante y los espejos a SU preferencia.

Con el código, el formato afecta su comodidad al leer y comprender el código. Si está demasiado lejos de lo que está acostumbrado, requerirá más esfuerzo mental. ¿Es necesario infligir esto a los desarrolladores?

+1 a todos los beneficios mencionados hasta ahora, pero ...

La aplicación automática conlleva costos que deben considerarse:

-1 al hecho de que los formateadores de código no entienden la estética del formato de código. ¿Cuántas veces ha tenido un formateador de código que destruye un bloque de comentarios que estaba bien alineado en forma de tabla? ¿Cuántas veces alineaste a propósito una expresión compleja de cierta manera para aumentar la legibilidad, solo para que el formato automático la convierta en algo que "sigue las reglas", pero que es mucho menos legible?

A veces hay soluciones para estas cosas, pero los desarrolladores tienen cosas más importantes en las que pensar que cómo evitar que el formateador automático estropee el código.

Tenga reglas de formato, pero permita cierta libertad para aplicar el sentido común.

swpalmer
fuente
2
¡Estoy absolutamente de acuerdo! Los autoformatos son tontos.
Łukasz Wiktor
1

Los buenos desarrolladores son personas creativas, deles una licencia artística. "Mantenlo simple" debería ser el mantra de los programadores. Tengo dos reglas:

Regla 1: Dé variables / cursores / objetos / procedimientos / cualquier NOMBRE SENSIBLE. Nombres inequívocos que aportan significado y comprensión a su código.

Regla 2: use sangría para mostrar la estructura de su código.

Eso es.

Jonesi
fuente
1
¿Podría explicar por qué este es el caso? ¿De qué manera permitir que cada desarrollador tenga alguna licencia artística (que difiere entre los desarrolladores en el mismo proyecto) es una mejor idea que tener todos ellos con el mismo formato? ¿Hay algún problema que el tuyo resuelva que la alternativa no? ¿Y viceversa?
Supongo que el punto que intento (y no logro) es que el uso de nombres razonables y la sangría de su código es mucho más importante con respecto a la legibilidad / mantenibilidad que otras reglas que le gustaría inventar. No estoy diciendo que todos en el equipo deberían tener su propio estilo, solo que si lo hacen, entonces, ¿qué?
Jonesi
Considere si tengo un formateador de código en eclipse configurado de una manera y siempre reformateo mi código ... y usted tiene uno configurado de manera ligeramente diferente ... y seguimos modificando el mismo código. ¿Esta 'licencia artística' causa algún problema en las diferencias?
Si bien entiendo lo que está diciendo, creo que un problema con su punto de vista es cuando tiene estilos muy diferentes (tenga en cuenta, no está mal, solo es diferente). Esto puede causar problemas reales y retrasos al fusionar estos diferentes estilos.
Daniel Hollinrake
1
Sí, entiendo tu punto Daniel. Debería agregar una tercera regla: al modificar el código existente, adáptelo para que coincida con el estilo del código que está editando. Esto es lo que haría naturalmente si estuviera arreglando un programa antiguo.
Jonesi
0

Para mí, la principal ventaja de un formato común aplicado automáticamente es que ayuda a nuestro seguimiento de cambios y revisiones de código. git (y la mayoría de las otras herramientas de control de código fuente) pueden mostrar diferencias de versiones anteriores de los archivos. Al imponer un estilo común, minimiza las diferencias de preferencia del programador.

Kristian H
fuente
-1

Son idiomas, no códigos. Los humanos tenemos más de 6000 idiomas, así que los traducimos. Entonces, si desea que sus "códigos" se comuniquen, tendrá que hacer sus ajustes. Verá que los usuarios tenemos que cambiar nuestros formatos de datos para que no los perdamos.

vic belleli
fuente
-2

Yo diría que no lo es. Definitivamente, una estructura / formato de código común entre un equipo es algo bueno, pero su aplicación automática no lo es. Esto debería ser hecho por humanos, no por la computadora.

Mis mayores problemas con el concepto son

  1. Si estoy escribiendo código en un formato y se reformatea automáticamente, ¿qué incentivo hay para aprender ese formato?
  2. Siguiendo ese punto anterior, si no aprende el formato, todo el punto de autoformato (para hacer que el código sea más fácil de leer y modificar) se pierde por completo. Todavía tiene que tomarse el tiempo para descubrir el formato mientras lee el código porque no ha aprendido ese formato
  3. Creo que sería una experiencia discordante como desarrollador escribir una clase un día, cerrarla y regresar al día siguiente para ver que es completamente diferente. Eso significa que los demás no solo tienen que aprender tu código, sino que también debes aprenderlo.
  4. También podría alentar la codificación diferida. En lugar de presionar al desarrollador para que aprenda el formato, pueden escribir en cualquier formato bajo el sol y automáticamente se verá como todos los demás lo desean. Esto vuelve al # 2 donde no aprendes el estilo y aún no puedes leerlo correctamente.

Ahora, podría inclinarme a decir que sería una buena idea ejecutar un formateo automático en un proyecto que está todo terminado. Esto comenzaría cada desarrollador en el mismo pie para el proyecto cuando vaya a arreglar / agregar características más adelante. Sin embargo, durante el desarrollo activo, creo que es una elección muy mala.

Básicamente: asigne la responsabilidad al empleado de aprender el estilo de la empresa, no obligue a que su código sea algo que no es.

Josh Janusch
fuente
+1: Buenos puntos, aunque no estoy seguro de que superen las razones a favor del reformateo automático. ¿Por qué el downvote (s)?