Sono abituato al fatto che il mio compilatore si lamenta quando faccio qualcosa di stupido come un errore di battitura su un nome di variabile, ma JavaScript ha l'abitudine di lasciarlo passare.
Esistono strumenti di analisi statica per JavaScript?
Sono abituato al fatto che il mio compilatore si lamenta quando faccio qualcosa di stupido come un errore di battitura su un nome di variabile, ma JavaScript ha l'abitudine di lasciarlo passare.
Esistono strumenti di analisi statica per JavaScript?
Risposte:
Sono d'accordo che JSLint è il miglior punto di partenza. Tieni presente che JavaScript Lint è diverso da JSLint . Suggerirei anche di dare un'occhiata a JSure , che nei miei test limitati ha funzionato meglio di entrambi, anche se con alcuni spigoli nell'implementazione: la versione Intel per Mac si è bloccata all'avvio per me, sebbene la versione PowerPC funzionasse bene anche su Intel e anche la versione per Linux funzionava bene. (Lo sviluppatore, Berke Durak, ha detto che mi avrebbe contattato quando il problema fosse stato risolto, ma non ho avuto sue notizie.)
Non aspettarti tanto dall'analisi statica JavaScript quanto da un buon correttore C. Come mi ha detto Durak, "qualsiasi analisi non banale è molto difficile a causa della natura dinamica di Javascript".
(Un altro bug, ancora più oscuro solo per Mac, questa volta con il widget Konfabulator di JSLint: trascinando l'icona di un documento BBEdit sul widget si sposta il documento nel cestino. Lo sviluppatore, Douglas Crockford, non aveva provato il widget su un Mac.)
10 agosto 2009: oggi allo Static Analysis Symposium , Simon Holm Jensen ha presentato un documento su TAJS: Type Analyzer for JavaScript , scritto con Anders Møller e Peter Thiemann. Il documento non menziona gli strumenti di cui sopra, ma Jensen mi ha detto che aveva guardato alcuni di loro e non era rimasto impressionato. Il codice per TAJS dovrebbe essere disponibile quest'estate.
RISPOSTA AGGIORNATA, 2017: Sì. Usa ESLint. http://eslint.org
Oltre a JSLint (già menzionato nella risposta di Flash Sheridan ) e al compilatore Closure (menzionato in precedenza nella risposta di awhyte ) ho anche ottenuto molti vantaggi dall'esecuzione di JSHint e PHP CodeSniffer . A partire dal 2012, tutti e quattro gli strumenti sono open source gratuiti e hanno alle spalle una comunità di sviluppatori ampia e attiva. Sono ognuno un po 'diverso (e penso complementare) nei tipi di controlli che eseguono:
JSLint è stato progettato per essere, ed è tuttora, lo strumento di pelucchi personale di Douglas Crockford. Viene fornito con un ottimo set di regole predefinito: quello di Crockford, costantemente aggiornato mentre continua a conoscere JavaScript e le sue insidie. JSLint è altamente supponente e questo è generalmente visto come una buona cosa. Quindi c'è (intenzionalmente) una quantità limitata che puoi fare per configurare o disabilitare le singole regole. Ma questo può rendere difficile applicare JSLint al codice legacy.
JSHint è molto simile a JSLint (infatti è nato come fork di JSLint) ma è più facile / possibile configurare o disabilitare tutti i controlli di JSLint tramite le opzioni della riga di comando o tramite un .jshintrc
file .
Mi piace particolarmente il fatto di poter dire a JSHint di segnalare tutti gli errori in un file, anche se ci sono centinaia di errori. Al contrario, sebbene JSLint disponga di maxerr
un'opzione di configurazione, generalmente viene eseguito il salvataggio relativamente presto quando si tenta di elaborare file che contengono un numero elevato di errori.
Il compilatore Closure è estremamente utile in quanto, se il codice non si compila con Closure, puoi essere certo che detto codice sia profondamente risucchiato in qualche modo fondamentale. La compilazione della chiusura è forse la cosa più vicina che c'è nel mondo JS a un controllo della sintassi "interprete" come php -l
oruby -c
La chiusura ti avverte anche di potenziali problemi come parametri mancanti e variabili non dichiarate o ridefinite. Se non vedi gli avvisi che ti aspetti, prova ad aumentare il livello di avviso invocando Chiusura con un'opzione di--warning_level VERBOSE
PHP CodeSniffer può analizzare JavaScript , PHP e CSS. CodeSniffer viene fornito con diversi standard di codifica, (diciamo phpcs -i
di vederli) che includono molti utili sniff per il codice JavaScript inclusi i controlli contro le strutture di controllo in linea e gli spazi bianchi superflui .
Ecco un elenco di JavaScript sniff disponibili in PHP CodeSniffer a partire dalla versione 1.3.6 ed ecco un set di regole personalizzato che ti permetterebbe di eseguirli tutti in una volta. Utilizzando set di regole personalizzate, è facile scegliere e scegliere le regole che si desidera applicare. E puoi anche scrivere le tue annusate se vuoi applicare un particolare "stile casalingo" che non è supportato immediatamente. Afaik CodeSniffer è l'unico strumento dei quattro qui menzionati che supporta la personalizzazione e la creazione di nuove regole di analisi statica. Un avvertimento però: CodeSniffer è anche il più lento di tutti gli strumenti menzionati.
Il compilatore JS "Closure" di Google produce avvisi ed errori configurabili in fase di compilazione. Trova sicuramente variabili e metodi con errori di ortografia, oltre a errori arity. Se sei disposto a scrivere JsDoc nel modo Closure, può fare molto anche con le informazioni sul tipo.
Anche lo strumento YUI "Compressor" può produrre avvisi, ma non l'ho ancora provato.
Non ho avuto molta fortuna con l'IDE Aptana, costruito su Eclipse, ma ad altre persone piace. Vedere la discussione di Stack Overflow sugli IDE JS.
L'IDE IntelliJ, che non è gratuito l'ultima volta che ho controllato, ha un eccellente supporto JS. Rileverà ed evidenzierà le variabili ei metodi con errori di ortografia durante la digitazione e altro ancora. Ha anche il completamento automatico.
In sintesi, JSLint, JSHint, Plato, ESLint, Google Closure-Linter sono gli strumenti disponibili. Ho riscontrato problemi di installazione mentre provavo Google Closure-Linter per Windows. Tuttavia, nella pagina Web viene menzionato che il suo supporto per Windows è sperimentale. Ho trovato e provato un altro strumento che funziona bene. Ecco il link per esso: http://esprima.org/
Inoltre, questo è il collegamento github per lo strumento Esprima: https://github.com/ariya/esprima
Puoi vedere alcuni strumenti per l'analisi del codice statico JavaScript in questo Wiki .
Uno strumento nel Wiki, ma non menzionato in questo post, è DeepScan . Il suo obiettivo è trovare errori di runtime e problemi di qualità piuttosto che le convenzioni di codifica dei linter. Copre anche TypeScript, React e Vue.js.
Puoi provarlo per il tuo progetto GitHub.
Ho provato ESlint e l'ho trovato buono .. puoi anche aggiungere regole personalizzate lì .. Ecco il repository github: https://github.com/nzakas/eslint ed ecco l'introduzione: http: // www. nczonline.net/blog/2013/07/16/introducing-eslint/
È possibile trovare una maggiore attenzione alla sicurezza rispetto all'elenco di scopi generali sul Wiki di Mozilla in Analisi del codice di sicurezza / B2G / JavaScript
Lo scopo di questo documento è raccogliere strumenti di analisi del codice JavaScript adatti per essere inclusi nei prossimi progetti Mozilla o per uso interno.
Inoltre, esiste almeno un prodotto commerciale che esegue l'analisi della sicurezza: Burp ottiene nuove funzionalità di analisi JavaScript
L'ultima versione di Burp include un nuovo motore per l'analisi statica del codice JavaScript. Ciò consente a Burp Scanner di segnalare una serie di nuove vulnerabilità, tra cui:
- XSS basato su DOM
- Iniezione di JavaScript
- SQL injection lato client
- WebSocket dirottamento
- Manipolazione del percorso del file locale
- Reindirizzamento aperto basato su DOM
- Manipolazione dei cookie
- Manipolazione dell'intestazione della richiesta Ajax
- Denial of service basato su DOM
- Manipolazione dei messaggi Web
- Manipolazione dell'archiviazione HTML5
In ambito commerciale, Coverity Static Analysis supporta l'analisi di JavaScript a partire dalla versione 7.7 (metà 2015). Per quanto riguarda la tua richiesta specifica sugli errori di battitura, il mio progetto preferito che appare nell'ultima versione (8.0, inizio 2016) trova errori di battitura di nei nomi degli elementi del programma.
In qualità di sviluppatore chiave del progetto, per favore accetta la mia spina spudorata: sebbene non sia ancora maturo come la venerata analisi C / C ++ , l'analisi JavaScript di Coverity condivide gran parte dello stesso motore, con la stessa attenzione alla ricerca di difetti di alto valore con un basso tasso di segnalazioni di difetti falsi positivi. Stiamo aumentando la nostra attenzione sulla ricerca di difetti di sicurezza in JavaScript (e altri linguaggi), oltre a trovare errori di programmazione generali.
Ora, ecco alcuni errori di battitura che trova (errore di battitura esatto lasciato come esercizio per il lettore, per sottolineare con quanta facilità questi possono essere trascurati):
merge.js: (collegamento stabile) (ultima revisione)
comandi-packages-query.js: (collegamento stabile) (ultima revisione)
series-pie-tests.js: (collegamento stabile) (ultima revisione)
outline_case.js: (collegamento stabile) (ultima revisione)
Mi piace Jslint per questo genere di cose ...
Flow esegue analisi statiche con e senza annotazioni.
Se hai bisogno di annotazioni, la sintassi è compatibile con TypeScript .
Installa il pacchetto con:
npm install --global flow-bin
Ci sono anche alcuni strumenti. Dai un'occhiata a gulp-flowtype e forse SublimeLinter-flow
JSAnalyse è stato appena pubblicato su codeplex. È uno strumento che analizza le dipendenze tra i file javascript. È anche possibile definire le dipendenze consentite e JSAnalysis verifica se le regole definite sono soddisfatte o meno. Ciò consente di tenere traccia delle dipendenze di javascript anche in grandi progetti e di avere un'architettura pulita.
JSAnalyse può essere eseguito come uno strumento da riga di comando o configurato tramite il diagramma dei livelli di Visual Studio. È anche facile da integrare nella build. Con i check-in gated puoi tenere sotto controllo le dipendenze.
Il nostro SD ECMAScript CloneDR è uno strumento per trovare copie esatte e quasi mancate di codice duplicato su grandi basi di codice sorgente JavaScript.
Utilizza la sintassi del linguaggio per guidare il rilevamento, quindi troverà cloni nonostante i cambiamenti di formato, commenti inseriti / cancellati, variabili rinominate e anche alcune istruzioni inserite / cancellate.
Il sito ha un esempio di CloneDR eseguito sulla libreria Closure di Google.
Divulgazione completa, io sono dietro questo: http://www.toptensoftware.com/minime che fa minification, offuscamento e una ragionevole serie di controlli di stile lint.