2009-12-23 41 views
14

Mantengo la compilación para un gran proyecto Java EE/Maven/Hudson/Perforce con aproximadamente 20 desarrolladores repartidos por todo el mundo.Mejores prácticas para el formato de código en proyectos grandes

La solución in situ para el formato del código es formatear la base de código usando Jalopy cuando el desarrollador ejecuta la compilación, garantizando así que cualquier código que no haya sido formateado sea formateado antes del check-in.

El principal problema de esta solución es que si el desarrollador no ejecuta una compilación completa de Maven antes de realizar el check-in (dicen que ejecutan las pruebas unitarias desde Eclipse), su código no se formateará. Entonces, el próximo desarrollador que edite el archivo puede tener muchas, muchas diferencias en las secciones no relacionadas del código después de ejecutar el formateador.

¿Qué estrategia de formato de origen ha funcionado mejor para usted en proyectos grandes? Otra opción que había considerado es formatear todas las noches mediante un proceso automatizado.

Respuesta

16

La compilación de Maven debería informar errores de formateo utilizando algo como Checkstyle y no formatear el código automáticamente. Eso es lo que su descripción parecía implicar. De esta forma, los errores se informan al desarrollador/Hudson en el momento de la compilación y se pueden resolver según sea necesario.

También sugiero usar una herramienta como Sonar para mantener un historial de errores de formato a lo largo del tiempo (consulte la funcionalidad de la máquina del tiempo).

1

¿Se puede establecer una regla de registro en Perforce para formatear el código al registrarse? No he usado forzosamente, así que no puedo comentar, pero este es el tipo de cosa que pensamos que sería apropiado cuando discutimos las opciones de aplicación de formato de código en nuestro equipo.

2

Si todos (o la mayoría) de sus desarrolladores usan Eclipse, puede exportar las reglas de formato y guardar acciones para el gusto de su equipo y hacer que todos compartan las mismas preferencias.

+1

He visto esto fallar varias veces. Me parece mucho más fácil hacer un seguimiento/hacer cumplir las reglas si está integrado en el proceso de construcción automatizado utilizando Maven/Checkstyle/Hudson. –

+1

No estaba sugiriendo que esto sea lo único que haces. De todas formas, debería seguir utilizando Checkstyle; esto facilitaría la corrección del formateo en el momento de escribir el código, en lugar de hacerlo después. –

+0

En ese caso, sugeriría usar el complemento Checkstyle Eclipse y configurarlo para usar las mismas reglas que Hudson. –

0

Esto puede no ser de mucha ayuda, pero el Go language source tree formatea automáticamente lo que inserta en él, utilizando una aplicación de línea de comandos que han configurado. Está hecho en Mercurial, no en Perforce. Pero, tal vez puedas ver cómo lo hicieron. Los detalles deben estar en algún lugar en golang.org.

6

Una manera de manejar esto sería formatear el código en un gancho pre comprometerse con algo como Jalopy o JIndent o incluso Eclipse formateador de código incorporado (que pueda invoke from the command line). AFAIK, esta es la única manera de asegurarse de que el código versionado sea siempre correctamente formateado si no puede obligar a las personas a ejecutar una compilación automática antes de comprometerse. Pero no sé si Perforce admite ganchos de precompromiso.

Si no es así, otra opción sería usar Jalopy Maven Plugin o Maven Checkstyle Plugin en tiempo de compilación y hacer que la compilación falle cuando se rompa una regla (y hacer que el motor de CI lo informe). Sin embargo, las fallas de compilación para cosas cosméticas pueden ser bastante molestas.

De hecho, ejecutar un proceso nocturno para formatear el código podría ser una alternativa. En ese caso, el Jalopy Maven Plugin o las otras herramientas mencionadas pueden ayudarlo, de hecho dependerá si desea usar Maven o no para este trabajo.

0

Si el formato adecuado es esencial para usted, configure Perforce para que ejecute su propio formateo al registrarse y dígale que rechace la confirmación si la versión formateada del archivo fuente es diferente de la enviada.

Personalmente solo utilizamos Eclipse Save Actions, y le pedimos que vuelva a formatear al guardar. Lo suficientemente bueno para nosotros.

14

Para obtener un formato coherente para sus proyectos, necesita configurar las herramientas para hacerlo automáticamente. Yo sugeriría lo siguiente:

Eclipse formateador

para Eclipse no es una opción en Preferencias (Java-> Código Style-> formateador), donde puede configurar cómo desea que sus proyectos para ser formateados. Crea un nuevo perfil y pon tu configuración allí.

Una vez que termine, hay una función de exportación (está bien oculta, haga clic en Editar y luego en Exportar). Pase la configuración al resto del equipo para que la pueda importar.

Eclipse Guardar acciones

Todavía tiene el formateador configurado no le garantía de que los desarrolladores podrán dar formato al código antes de comprometerse por lo que necesita para configurar el formato automático.

Ve a Preferencias nuevamente (Java-> Editor-> Guardar acciones) y selecciona Formatear código fuente. De esta forma, el código se formatea mientras se guarda el archivo.

Eclipse Plugin Checkstyle

Algunos desarrolladores pueden olvidarse de hacer estos pasos correctamente, por lo que necesita una manera de localizar eso.

instalar el plugin para Eclipse Checkstyle:

Una vez instalado el plugin, puedes crear una configuración para eso. La configuración se puede exportar para el resto del equipo, o incluso mejor cargarse en un servidor y hacer referencia a la configuración de forma remota.

La ventaja de tener una configuración remota es que también puede hacer referencia a ella mediante maven-checkstyle-plugin y puede proporcionarle informes mediante su inicio en un servidor de CI.

Si quieres ser duro, puedes establecer la configuración básica (las que realiza automáticamente el formateador) en errores en lugar de advertencias para que el desarrollador con un eclipse mal configurado vea el error antes de comprometerse.

preconfigurado Eclipse

Si quieres ir al siguiente nivel, se crea un eclipse preconfigurado, y distribuir esa versión para sus desarrolladores por lo que no tienen que hacer nada.

Bonificación de efecto secundario: se mantienen al margen las inconsistencias de versión en la plataforma de desarrollo. Configuration Management no se trata solo del código fuente, sino también de las herramientas de desarrollo. Mantiene las cosas más predecibles

+1

Eclipse es una forma terrible de reformatear el código. Nuestra experiencia es que no reformatea sistemáticamente todos los archivos, por lo que crea diferencias entre las ramas a lo largo del tiempo. Jalopy, Jacobe, JIndent, o algo así es preferible. – cdunn2001

2

La mejor solución que he visto para este es el enfoque adoptado por CXF, se describe en detalle en Connecting Maven, Eclipse, Checkstyle, and PMD.

Integran checkstyle con Eclipse, utilizando el complemento Eclipse-cs que Dimitris mencionó en otra respuesta. Esto permite a Eclipse generar errores si su código rompe las reglas de formato del código. También integran checkstyle con Maven, por lo que el paso de verificación fallará si su código no cumple con las reglas de estilo de control. También tienen un conjunto redundante de reglas de formato automático definidas dentro de Eclipse, lo que hace que sea fácil formatear rápidamente el código que pasará los estándares del estilo de control.

Esto implica una gran cantidad de configuración para Eclipse. Automatizan este paso al reunir una colección de complementos de Maven que generarán un espacio de trabajo específico de CXF, que incluye la configuración necesaria de estilo de control/autoformato.

Cuestiones relacionadas