2010-04-28 36 views

Respuesta

11

Checkstyle es una herramienta de desarrollo para ayudar a los programadores escribir código Java que se adhiere a un estándar de codificación. Automatiza el proceso de comprobación del código Java para ahorrarle a los humanos esta tarea aburrida (pero importante). Esto lo hace ideal para proyectos que desean aplicar un estándar de codificación. Checkstyle es altamente configurable y se puede hacer para soportar casi cualquier estándar de codificación. Se proporciona un archivo de configuración de ejemplo que admite las Convenciones de Sun Code. Además, se suministran otros archivos de configuración de muestra para otras convenciones conocidas.

PMD está integrada con JDeveloper, Eclipse, JEdit, JBuilder, BlueJ, CodeGuide, NetBeans/Sun Java Studio Enterprise/Creador, IntelliJ IDEA, TextPad, Maven, Ant, Gel, JCreator y Emacs.

FindBugs utiliza el análisis estático para inspeccionar el código de bytes de Java para las ocurrencias de los patrones de errores. El análisis estático significa que FindBugs puede encontrar errores simplemente inspeccionando el código de un programa: la ejecución del programa no es necesaria. Esto hace que FindBugs sea muy fácil de usar: en general, debería poder usarlo para buscar errores en su código en unos minutos después de descargarlo. FindBugs funciona analizando el bytecode de Java (archivos de clase compilados), por lo que ni siquiera necesita el código fuente del programa para usarlo. Debido a que su análisis es a veces impreciso, FindBugs puede informar advertencias falsas, que son advertencias que no indican errores reales. En la práctica, la tasa de advertencias falsas informadas por FindBugs es inferior al 50%.

+0

PMD está integrado en jDeveloper, ¿necesita "activarlo"? Lo hace funcionar por defecto? NM- Acabo de mirar el http://pmd.sourceforge.net/integrations.html y parece que necesita ser instalado y luego activado. Pensé que estaba integrado. – ProfessionalAmateur

4

Uso Checkstyle para asegurarme de que el código sigue ciertas reglas. Checkstyle también está disponible como plugin for Eclipse.

+0

El enlace no funciona para verificar e intentado configurar también en el Eclipse – gmhk

+0

Ambos enlaces funcionan para mí. Si hay un problema con la instalación del complemento en su máquina, no es mi culpa. Entonces, ¿por qué downvote? – Ham

2

¿Qué pasa con un poco de autodisciplina? Si no puede hacerlo por algo tan trivial como el formateo, no tengo muchas esperanzas para otros aspectos de calidad del código.

+0

¿Cómo puede estar seguro de que cada persona en su equipo conoce las convenciones del código? – folone

+0

@folone, cuando @Tim Hawtin - tackline ejecuta el código de su equipo a través de Checkstyle, sin duda es 100% perfecto cada vez. Ojalá pudiera decir lo mismo de mi código. –

+0

Hay una filosofía de desarrollo que un humano nunca debe hacer lo que una computadora puede hacer. Sí, al escribir el código, se adhiere a las convenciones el 95% del tiempo. ¿Ahora paso una hora buscando ese 5% final o simplemente uso una herramienta como 'jalopy' o el formateador de eclipses para hacerlo por mí? Te daré una suposición. – bgiles

0

Usamos Checkstyle en mi empresa, pero solo para cheques javadoc.

Es bueno en la forma en que puede configurar diferentes módulos para incluir cosas para verificar, y también en qué niveles (como en protegido, público, privado, etc.).

Un heads-up es que para javadoc-checking necesita indicar explícitamente si un método está permitido throw varias excepciones. Esto es así porque los creadores piensan que es un mal diseño tener un método que arroje más de una excepción (en otras palabras, intentan controlar el diseño, no está relacionado en mi humilde opinión).

5

Checkstyle y FindBugs y PMD. Los dos últimos son mucho más que simples herramientas de estilo. Pero generalmente hay que esforzarse para lograr un acuerdo entre los miembros del equipo y la configuración de la herramienta.

0

Tener un documento de estándares de codificación que se distribuye a todos los desarrolladores en el equipo/departamento/organización es un buen comienzo.

+1

No estoy seguro, cómo se asegura que todos lo lean y lo recuerden, incluso después de cada pequeño cambio. Si quiere asegurarse de que la gente pierda mucho esfuerzo y motivación. De lo contrario, será solo otro documento que nadie lea. – bertolami

+0

Su uso tiene que ser obligatorio. Si desea tener un estándar de codificación, necesita alguna forma de describir ese estándar y una política para garantizar que todos se adhieran al estándar. Su estándar de codificación no debería tener muchos pequeños cambios realizados una vez publicados. He descubierto que la mejor manera es tener un acuerdo de alto nivel sobre estándares básicos de codificación (como legibilidad y claridad) y no preocuparse demasiado por las minucias de la ubicación del bracket, etc. YMMV. Obviamente, los desarrolladores junior necesitan más orientación que los más experimentados. – t0ne

4

Además de lo anterior, Jalopy es una buena herramienta para formatear el código.

0

Las advertencias del compilador de eclipse y el formateador de código hacen el trabajo por nosotros. Aunque soy consciente de que el estilo de comprobación hace un poco más de comprobación semántica para el diseño real del código, en lugar de simplemente exponerlo con sensatez.

4

Puede echar un vistazo a Sonar. Es un proyecto de código abierto que realmente facilita la ejecución de Checkstyle, PMD y Findbugs.

Cuestiones relacionadas