Estoy acostumbrado a tener mi compilador quejarse cuando hago algo estúpido como un error tipográfico en un nombre de variable, pero JavaScript tiene la costumbre de dejar pasar esto.¿Hay alguna herramienta de análisis estático de JavaScript?
¿Hay alguna herramienta de análisis estático para JavaScript?
Estoy de acuerdo que JSLint es el mejor lugar para empezar. Tenga en cuenta que JavaScript Lint es distinto de JSLint. También sugiero verificar JSure, que en mis pruebas limitadas fue mejor que cualquiera de ellos, aunque con algunas asperezas en la implementación: la versión de Intel para Mac se bloqueó en el inicio para mí, aunque la versión de PowerPC funcionó bien incluso con Intel, y la versión de Linux corrió bien también. (El desarrollador, Berke Durak, dijo que me respondería cuando esto se solucionara, pero no he tenido noticias suyas)
No esperes tanto del análisis estático de JavaScript como obtienes de un buen C corrector. Como Durak me dijo, “cualquier análisis no trivial es muy difícil debido a la naturaleza dinámica de Javascript.”
(Otro, incluso sólo para Mac error más oscura, esta vez con widget de Konfabulator de JSLint: Al arrastrar un icono de documento BBEdit en el Reproductor mueve el documento a la basura el desarrollador, Douglas Crockford, no se había intentado el widget en un Mac)
10 agosto de 2009:.. Hoy en el Static Analysis Symposium, Simon Holm Jensen presentó un documento sobre TAJS: Type Analyzer for JavaScript, escrito con Anders Møller y Peter Thiemann. El documento no menciona las herramientas anteriores, pero Jensen me dijo que había mirado a algunas y que no estaba impresionado. El código para TAJS debería estar disponible en algún momento de este verano.
Pity JSLint está en línea solamente. – UpTheCreek
@UpTheCreek: JSLint está disponible en GitHub. –
@Dave oh, bien, eso es genial :) – UpTheCreek
me gusta Jslint para este tipo de cosas ...
Cool. Encontré un plugin de Eclipse para JSLint en http://www.rockstarapps.com/joomla-1.5.8/products/jslint-eclipse-plugin.html, que también se ve bastante bien. Tenga en cuenta que es necesario instalar desde el 'sitio de actualización de Eclipse para la versión beta de jsLex 1.2.2' para obtener la funcionalidad de JSLint. – Mat
Google's "Closure" JS compiler produce avisos y errores configurables en tiempo de compilación. Definitivamente encuentra variables y métodos mal escritos, más errores de aridad. Si está dispuesto a escribir JsDoc the Closure, también puede hacer mucho con la información del tipo.
La herramienta "Compresor" YUI también puede producir advertencias, pero aún no lo ha intentado.
No he tenido mucha suerte con el IDE de Aptana, construido en Eclipse, pero otras personas como él. Consulte la discusión de Desbordamiento de pila de los IDE de JS.
El IntelliJ IDE, que no es gratuito el último que verifiqué, tiene una excelente compatibilidad con JS. Detectará y resaltará vars mal escritos y métodos a medida que escribe, y más. También tiene autocompletar.
Nuestra SD ECMAScript CloneDR es una herramienta para encontrar exacta y casi-copias de código duplicado a través de grandes bases de código fuente de JavaScript.
Utiliza la sintaxis del lenguaje para guiar la detección, por lo que encontrar clones a pesar de los cambios de formato, comentarios insertados/borrados, renombraron las variables e incluso algunos insertadas/suprimidas declaraciones.
El sitio tiene una muestra CloneDR ejecutada en la biblioteca de cierre de Google.
¿Alguien ha intentado esto todavía? No encontré ningún botón de descarga o pedido ... –
@Sven: pregunte en el sitio web. –
... Desde enero de 2011 ... hay un enlace de descarga que puede usar para obtener una copia de evaluación de CloneDR para JavaScript (o varios otros idiomas) para jugar. –
Divulgación completa, estoy detrás de esto: http://www.toptensoftware.com/minime que hace la minificación, ofuscación y un conjunto razonable de controles de estilo de pelusa.
JSAnalyse acaba de ser publicado en codeplex. Es una herramienta que analiza las dependencias entre los archivos javascript. Incluso puede definir las dependencias permitidas y JSAnalysis verifica si las reglas definidas se cumplen o no.Eso permite hacer un seguimiento de las dependencias de javascript incluso en grandes proyectos y tener una arquitectura limpia.
JSAnalyse puede ejecutarse como una herramienta de línea de comandos o configurarse a través del Diagrama de Capa de Visual Studio. También es fácil de integrar en la construcción. Con check-ins cerrados puede mantener las dependencias bajo control.
RESPUESTA actualizada, 2017: Sí. Use ESLint. http://eslint.org
Además de JSLint (ya mencionada en Flash Sheridan's answer) y el Closure compiler (anteriormente mencionado en awhyte's answer) He También he recibido una gran cantidad de beneficios de correr JSHint y PHP CodeSniffer. A partir de 2012, las cuatro herramientas son de código abierto gratuito y tienen una gran comunidad de desarrolladores activa detrás de ellas. Son todas diferentes entre sí (y creo que, complementaria) en los tipos de controles que realizan:
JSLint fue diseñado para ser, y sigue siendo la herramienta pelusa personal de Douglas Crockford. Se envía con un gran gran conjunto de reglas - de Crockford, constantly updated como él continues to learn sobre JavaScript y sus peligros. JSLint es highly opinionated y esto generalmente es seen as a good thing. Por lo tanto hay (intencionalmente) un limited amount que puede hacer para configurar o deshabilitar reglas individuales. Pero esto puede dificultar la aplicación de JSLint al código heredado.
JSHint es muy similar a JSLint (de hecho began life como JSLint tenedor) pero es más fácil/posible configure or disable todos los cheques de JSLint a través de las opciones de línea de comandos o mediante un .jshintrc file.
Me gusta particularmente que puedo decirle a JSHint que informe todos los de los errores en un archivo, incluso si hay cientos de errores. Por el contrario, aunque JSLint tiene una opción de configuración maxerr, en general se rescatará relativamente temprano cuando intente procesar archivos que contengan grandes cantidades de errores.
El compilador de cierre es muy útil, ya que, si el código no compilará con cierre, puede sentirse muy seguro de dicho código es profundamente manguera de alguna manera fundamental. compilación de cierre es posiblemente lo más parecido que hay en el mundo JS a una comprobación de sintaxis "intérprete" como php -l o ruby -c
cierre también warns you about potential issues tales como parámetros faltantes y las variables no declaradas o redefinidos. Si usted no está viendo las advertencias que se pueden esperar, intente aumentar el nivel de advertencia invocando Cierre con una opción de --warning_level VERBOSE
PHP CodeSniffercan parse JavaScript, así como PHP y CSS. CodeSniffer se envía con varios estándares de codificación diferentes (por ejemplo, phpcs -i para verlos) que incluyen muchos olfactos útiles para el código JavaScript, incluidos los controles contra inline control structures y superfluous whitespace.
Aquí hay un list of JavaScript sniffs disponible en PHP CodeSniffer a partir de la versión 1.3.6 y aquí está un custom ruleset that would allow you to run them all at once. Usando reglas personalizadas, es fácil de pick and choose the rules que desea aplicar. Y puede incluso write your own sniffs si quiere imponer un "estilo de casa" particular que no se admite de inmediato. Afaik CodeSniffer es la única herramienta de las cuatro mencionadas aquí que admite la personalización y la creación de nuevas reglas de análisis estático. Sin embargo, una advertencia: CodeSniffer es también el que funciona más lentamente con cualquiera de las herramientas mencionadas.
Detección de copiar y pegar para código JavaScript ahora está disponible a través de CPD. ¡Que yo sepa, esta es la primera herramienta robusta de duplicación de código fuente abierto para JavaScript! http://pmd.sourceforge.net y vea también la pregunta "¿Hay una herramienta CPD como javascript?" http://stackoverflow.com/a/13745190/55478 –
probé ESlint y lo encontraron good..you también puede añadir reglas personalizadas there..Here es el repositorio GitHub: https://github.com/nzakas/eslint y aquí es la introducción a la misma: http://www.nczonline.net/blog/2013/07/16/introducing-eslint/
En resumen, JSLint, JSHint, Plato, ESLint, Google Closure-Linter son las herramientas disponibles. Tuve problemas de instalación al probar Google Closure-Linter para Windows. Pero, menciona en la página web que su soporte para Windows es experimental. Encontré y probé otra herramienta que funciona bien. Aquí está el enlace para ello: http://esprima.org/
Además, este es el enlace de GitHub para la herramienta Esprima: https://github.com/ariya/esprima
Más seguridad enfocado a la lista de propósito general se puede encontrar en el Mozilla Wiki en Security/B2G/JavaScript code analysis
El propósito de este documento es recopilar las herramientas de análisis de código JavaScript adecuadas para incluirse en los próximos proyectos de Mozilla o para uso interno .
También hay por lo menos un producto comercial que hace el análisis de seguridad: Burp gets new JavaScript analysis capabilities
La última versión de eructar incluye un nuevo motor para el análisis estático de código JavaScript. Esto permite a eructar escáner para informar de una gama de nuevas vulnerabilidades, incluyendo:
- basadas en DOM XSS
- JavaScript inyección
- de inyección SQL en el cliente
- WebSocket secuestro
- manipulación ruta del archivo local
- DOM redirección abierta
- Cookie manipulación
- Ajax manipulación encabezado de solicitud
- negación basada en DOM de servicio
- manipulación mensaje Web manipulación
- de almacenamiento HTML5
Flow hace análisis estático con y sin anotaciones.
Si necesita anotaciones, la sintaxis es compatible con TypeScript.
Instalar el package con:
npm install --global flow-bin
También hay algo de utillaje. Eche un vistazo a gulp-flowtype y quizás SublimeLinter-flow
En el ámbito comercial, Coverity Static Analysis admite el análisis de JavaScript a partir de la versión 7.7 (mediados de 2015). En cuanto a su consulta específica sobre errores tipográficos, mi proyecto favorito que aparece en la última versión (8.0, principios de 2016) encuentra errores tipográficos en los nombres de los elementos del programa.
Como desarrollador clave en el proyecto, acepte mi complemento desvergonzado: aunque todavía no es tan maduro como el venerated C/C++ analysis, el análisis de JavaScript de Coverity comparte mucho del mismo motor, con el mismo enfoque en encontrar defectos de alto valor con un bajo tasa de informes de defectos positivos falsos. Estamos aumentando nuestro enfoque en encontrar defectos de seguridad en JavaScript (y en otros idiomas), además de encontrar errores generales de programación.
Ahora, aquí hay algunos errores tipográficos que encuentra (exacta del error tipográfico deja como ejercicio para el lector, hacer hincapié en la facilidad con que estos pueden ser pasados por alto):
merge.js: (stable link)(latest revision)
comandos paquetes -query.js: (stable link)(latest revision)
serie-Pie-tests.js: (stable link)(latest revision)
outline_case.js: (stable link)(latest revision)
Puede ver algunas herramientas para el análisis de código estático de JavaScript en este Wiki.
Una herramienta en el Wiki, pero no se menciona en esta publicación, es DeepScan. Su objetivo es encontrar errores de tiempo de ejecución y problemas de calidad en lugar de codificar convenciones de linters. Cubre también TypeScript y React.
Puede probarlo para su proyecto GitHub.
ahora un día mecanografiado es tu amigo - admite la comprobación de tipo implícita de javascript y si quieres ir al 100% puedes escribir jsdoc3 o anotaciones de cierre de google e inferirá tipos desde allí. Los editores como vscode o webstorm lo admiten de fábrica: https://github.com/Microsoft/TypeScript/wiki/Type-Checking-JavaScript-Files – cancerbero