Devo usar a validação JSLint ou JSHint JavaScript? [fechadas]


454

Atualmente, estou validando meu JavaScript contra JSLint e progredindo, está me ajudando a escrever um JavaScript melhor - em particular no trabalho com a biblioteca Jquery.

Agora me deparei com o JSHint , um fork do JSLint .
Então, eu estou pensando em aplicativos da Web, que são muito direcionados para JavaScript, que é a ferramenta de validação melhor ou mais aplicável contra a qual:

  • JSLint ou JSHint?

Quero decidir agora sobre um mecanismo de validação e, adiante, use isso para validação do lado do cliente.

E diferença entre jshint e jslint? Por favor, explique no exemplo javascript único.

Ligações:

  1. jshint - http://www.jshint.com/

  2. jslint - http://jslint.com/


4
E o ESLint ? Embora seja imperfeito: Combine this with the previous 'var' statement-> Do not mix 'require' and other declarationsparadoxo.
precisa saber é o seguinte



Não é um desenvolvedor de JS. Mas achei o JSHint muito útil durante nosso processo de revisão de código. Eu recomendo.
Chetan Vashistth 15/07/19

Respostas:


156

[EDIT]
Esta resposta foi editada. Estou deixando a resposta original abaixo para o contexto (caso contrário, os comentários não fariam sentido).

Quando essa pergunta foi feita originalmente, o JSLint era a principal ferramenta de aprendizado de JavaScript. O JSHint era um novo fork do JSLint, mas ainda não havia divergido muito do original.

Desde então, o JSLint permaneceu praticamente estático, enquanto o JSHint mudou bastante - jogou fora muitas das regras mais antagônicas do JSLint, adicionou toda uma carga de novas regras e geralmente se tornou mais flexível. Além disso, outra ferramenta ESLint está agora disponível, que é ainda mais flexível e possui mais opções de regras.

Na minha resposta original, eu disse que você não deve se forçar a seguir as regras da JSLint; contanto que você entenda por que estava lançando um aviso, você poderia decidir se deve alterar o código para resolver o aviso ou não.

Com o conjunto de regras ultra-rigoroso do JSLint de 2011, este foi um conselho razoável - vi muito poucos conjuntos de códigos JavaScript que poderiam passar no teste JSLint. No entanto, com as regras mais pragmáticas disponíveis nas ferramentas JSHint e ESLint atuais, é uma proposta muito mais realista tentar fazer com que seu código passe por elas com zero aviso.

Ocasionalmente, ainda pode haver casos em que um linter reclamará de algo que você fez intencionalmente - por exemplo, você sabe que deve sempre usar, ===mas apenas dessa vez você tem um bom motivo para usá-lo ==. Mas mesmo assim, com o ESLint, você tem a opção de especificar em eslint-disabletorno da linha em questão, para que você ainda possa passar por um teste de aprovação com zero aviso, com o restante do código obedecendo à regra. (apenas não faça esse tipo de coisa com muita frequência!)


[RESPOSTA ORIGINAL SEGUE]

Por todos os meios, use JSLint. Mas não se preocupe com os resultados e com a correção de tudo o que avisa. Isso o ajudará a melhorar seu código e a encontrar bugs em potencial, mas nem tudo o que o JSLint reclama é um problema real; portanto, não sinta que precisa concluir o processo com zero avisos.

Praticamente qualquer código Javascript com tamanho ou complexidade significativo produzirá avisos no JSLint, não importa quão bem escrito seja. Se você não acredita em mim, tente executar algumas bibliotecas populares como o JQuery.

Alguns avisos do JSLint são mais valiosos que outros: saiba quais devem ser observados e quais são menos importantes. Todo aviso deve ser considerado, mas não se sinta obrigado a corrigir seu código para limpar qualquer aviso; Não há problema em olhar o código e decidir que você está feliz com ele; há momentos em que coisas que o JSlint não gosta são realmente a coisa certa a fazer.


3
A melhor parte do jsHint é que ele possui sinalizadores para aceitar o jQuery e não é irritante / estrito como jslint. Por exemplo: for (i = 0; i < dontEnumsLength; i++)joga Unexpected '++'onde está ok. etc.
RaphaelDDL

2
Por favor, não ignore as regras, esta é a pior coisa que você pode fazer com o linter. Basta configurá-lo ou, se você não puder, altere. JSHint e JSCs combinação é fantástico
AuthorProxy

JSHint diz "Esperava uma atribuição ou chamada de função e viu uma expressão". a um ternário usado apenas para operações. Documentação da Mozilla: diz "Você também pode usar avaliações ternárias em espaço livre para realizar operações diferentes". developer.mozilla.org/pt-BR/docs/Web/JavaScript/Reference/… @AuthorProxy Vou usar o Mozilla e ignorar o JSHint. Desculpa.
dewd

1
A essa altura, parece que o ESLint é a direção que o setor está seguindo em geral, juntamente com configurações populares como o airbnb.
Jinglesthula #

369

tl; dr takeaway :

Se você está procurando um padrão muito alto para você ou sua equipe, o JSLint. Mas não é necessariamente o padrão, apenas um padrão, alguns dos quais nos chegam dogmaticamente de um deus javascript chamado Doug Crockford. Se você quiser ser um pouco mais flexível, ou tiver alguns profissionais antigos em sua equipe que não concordem com as opiniões da JSLint, ou que estejam indo e voltando entre JS e outras línguas da família C regularmente, tente o JSHint.

versão longa :

O raciocínio por trás do fork explica muito bem por que o JSHint existe:

http://badassjs.com/post/3364925033/jshint-an-community-driven-fork-of-jslint http://anton.kovalyov.net/2011/02/20/why-i-forfor-jslint-to -jshint /

Então, acho que a ideia é que seja "dirigido pela comunidade" e não por Crockford. Na praticidade, o JSHint geralmente é um pouco mais brando (ou pelo menos configurável ou agnóstico) em algumas "opiniões" sintáticas estilísticas e secundárias nas quais o JSLint é um defensor.

Como exemplo, se você acha que A e B abaixo estão bons, ou se deseja escrever código com um ou mais dos aspectos de A que não estão disponíveis em B, JSHint é para você. Se você acha que B é a única opção correta ... JSLint. Tenho certeza de que existem outras diferenças, mas isso destaca algumas.

A) Passa JSHint fora da caixa - falha em JSLint

(function() {
  "use strict";
  var x=0, y=2;
  function add(val1, val2){
    return val1 + val2;
  }
  var z;
  for (var i=0; i<2; i++){
    z = add(y, x+i);
  }
})();

B) Passa JSHint e JSLint

(function () {
    "use strict";
    var x = 0, y = 2, i, z;
    function add(val1, val2) {
       return val1 + val2;
    }
    for (i = 0; i < 2; i += 1) {
        z = add(y, x + i);
    }
}());

Pessoalmente, acho o código JSLint muito agradável de se olhar, e os únicos recursos difíceis com os quais discordo são o ódio a mais de uma declaração var em uma função e var i = 0declarações for-loop e alguns dos reforços de espaço em branco para declarações de função .

Algumas das coisas em branco que o JSLint impõe, acho que não são necessariamente ruins, mas estão fora de sincronia com algumas convenções bastante comuns de espaços em branco para outras linguagens da família (C, Java, Python, etc ...), que geralmente são seguidas como convenções em Javascript também. Como estou escrevendo em vários desses idiomas ao longo do dia e trabalhando com membros da equipe que não gostam do espaço em branco no estilo Lint em nosso código, acho o JSHint um bom equilíbrio. Ele pega coisas que são um bug legítimo ou uma forma muito ruim, mas não latem para mim como o JSLint faz (às vezes, de maneiras que não posso desativar) pelas opiniões estilísticas ou detalhes sintáticos dos quais não me importo.

Muitas bibliotecas boas não são Lint'able, o que para mim demonstra que há alguma verdade na idéia de que algumas das JSLint estão simplesmente enviando 1 versão do "bom código" (que é, de fato, um bom código). Mas, novamente, as mesmas bibliotecas (ou outras boas) provavelmente também não são Hint'able, portanto, touché.


11
... Devo admitir que fiquei desapontado com a qualidade não profissional dos conselhos que vi recentemente proliferando com relação aos estilos de codificação para JS (e CSS também, aliás). É como se a paixão por um idioma específico tivesse anulado as necessidades de profissionais não especializados (ou seja, o público-alvo). É uma pena, considerando que eles precisam de bons conselhos, e seguirão cegamente e perpetuarão o que é apresentado como melhor prática, sem conhecer melhor. Muitas vezes, é incompatível com outros padrões adotados por comunidades de usuários mais estabelecidas para outros idiomas. :(
Lee Kowalkowski

67
@LeeKowalkowski O motivo pelo qual o JSLint desencoraja for (var i = 0; ...; i++)é porque ele não torna o loop auto-contido. O escopo de ié a função. A sintaxe parece estar criando um escopo de bloco, mas não é e leva os programadores e as pessoas com menos experiência em JavaScript que escrevem em vários idiomas a entender mal o escopo de uma variável e isso pode resultar em erros sutis. Muitos de nós (inclusive eu) talvez não gostemos de como colocar todas as declarações no topo, mas é um bom lembrete de que o JavaScript não tem escopo de bloco.
Mark Evans

25
@ MarkEvans É independente da visão de que, se você mover apenas o loop para outra função, inão se tornará acidentalmente global. O fato de que o iescopo da função e o escopo do bloco não é um motivo suficientemente bom para declarar variáveis ​​no topo, as variáveis ​​sempre devem ser declaradas o mais próximo possível de onde elas são usadas ( programmers.stackexchange.com/questions/56585/… ).
Lee Kowalkowski

17
@ MarkEvans Acho que você está se concentrando demais nos detalhes da implementação do idioma. Os padrões de programação devem ser para humanos, não para compiladores. A confiança em uma ferramenta de análise de código estática para capturar armadilhas comuns não substitui a adoção de bons hábitos que os evitam em primeiro lugar. Não consigo entender uma razão pela qual uma variável iteradora de um loop simples deve ser declarada a qualquer distância do loop que requer isso. Muitos padrões de codificação para outros idiomas dizem declarar variáveis ​​o mais próximo possível de onde elas são usadas, para facilitar a leitura. Não vi um bom motivo para não fazer isso no JS.
Lee Kowalkowski

11
O uso de uma variável iteradora fora de um loop é o que um linter deve verificar.
Lee Kowalkowski

61

Existe um outro "player" maduro e ativamente desenvolvido na frente do javascript - ESLint:

ESLint é uma ferramenta para identificar e relatar padrões encontrados no código ECMAScript / JavaScript. De muitas maneiras, é semelhante ao JSLint e JSHint, com algumas exceções:

  • O ESLint usa o Esprima para análise de JavaScript.
  • O ESLint usa um AST para avaliar padrões no código.
  • O ESLint é completamente plugável, cada regra é um plug-in e você pode adicionar mais em tempo de execução.

O que realmente importa aqui é que é extensível por meio de plugins / regras personalizados . Já existem vários plugins criados para diferentes propósitos. Entre outros , existem:

E, é claro, você pode usar sua ferramenta de criação de escolha para executar ESLint:


1
O valor de ter um linter executado em seu editor enquanto você digita não pode ser subestimado. ESLint é usado dessa maneira extensivamente. Eu nunca ouvi falar do suporte ao editor JSLint ou JSHint (1 ponto de dados anedótico).
Jinglesthula #

17

Eu tive a mesma pergunta há algumas semanas e estava avaliando o JSLint e o JSHint.

Ao contrário das respostas nesta pergunta, minha conclusão não foi:

Por todos os meios, use JSLint.

Ou:

Se você está procurando um padrão muito alto para você ou sua equipe, o JSLint.

Como você pode configurar quase as mesmas regras no JSHint e no JSLint. Então, eu argumentaria que não há muita diferença nas regras que você poderia alcançar.

Portanto, os motivos para escolher um sobre o outro são mais políticos do que técnicos.

Finalmente decidimos usar o JSHint pelos seguintes motivos:

  • Parece ser mais configurável que o JSLint.
  • Parece definitivamente mais voltado para a comunidade do que para um show individual (não importa o quão legal The Man seja).
  • JSHint correspondeu ao nosso estilo de código OOTB melhor que JSLint.

1
Obrigado por uma resposta curta e concisa. Isso resolveu meus espaços em branco sobre o problema.
akauppi

13

Eu faria uma terceira sugestão, o Google Closure Compiler (e também o Closure Linter ). Você pode experimentá-lo online aqui .

O Closure Compiler é uma ferramenta para tornar o download e a execução do JavaScript mais rápidos. É um verdadeiro compilador para JavaScript. Em vez de compilar de um idioma de origem para o código da máquina, ele compila do JavaScript para melhorar o JavaScript. Ele analisa seu JavaScript, analisa, remove código morto e reescreve e minimiza o que resta. Ele também verifica a sintaxe, as referências e os tipos de variáveis ​​e alerta sobre as armadilhas comuns do JavaScript.


4
O que o compilador de fechamento entende que o linter não faz?
James McMahon

4
Não vejo nenhum aviso gerado por essa ferramenta, quando certamente deveria. JSLint e JSHint produzem tantos avisos para a mesma entrada, que ambos emitem "muitos erros".
wallyk

6
usamos fechamento em um projeto recente e não o faria novamente. o linter não pode ser configurado para ativar determinadas verificações (muitas das quais são importantes para você) e o compilador realmente vale a pena se você estiver trabalhando exclusivamente com bibliotecas compatíveis com o fechamento (das quais realmente não existem fora do google).
Robert Levy

4
Isso não se refere ao Google Closure Comepiler por si só, mas as ferramentas do Google sempre devem ser analisadas com um pouco de sal. Eles foram criados para resolver objetivos específicos do Google e podem não coincidir com os seus objetivos.
Pacerier

@RobertLevy obrigado por comentar sua experiência que você teve ... eu estava lendo o guia de estilo do Google para javascript e recomendou o fechamento-compilador, pois é um programa para fiapos. Mas agora eu vejo há outros como JSLint e jshint
Trevor Boyd Smith

13

Prefácio: Bem, isso aumentou rapidamente. Mas decidiu fazê-lo. Que esta resposta seja útil para você e outros leitores.

Eu me empolguei um pouco aqui

Dica de código

Embora o JSLint e o JSHint sejam boas ferramentas para usar, ao longo dos anos eu passei a apreciar o que meu amigo @ugly_syntax chama:

menor espaço de design .

Este é um princípio geral, bem como um "monge zen", limitando as escolhas que se deve fazer; pode-se ser mais produtivo e criativo.

Portanto, meu estilo de código JS favorito de configuração zero atual:

StandardJS .

ATUALIZAÇÃO :

O fluxo melhorou muito. Com ele, você pode adicionar tipos ao seu JS para ajudá-lo a evitar muitos bugs. Mas também pode ficar fora do seu caminho, por exemplo, ao fazer interface com JS não tipado. De uma chance!

Início rápido / TL; DR

Adicionar standardcomo dependência ao seu projeto

npm install --save standard

Em seguida package.json, adicione o seguinte script de teste:

"scripts": {
    "test": "node_modules/.bin/standard && echo put further tests here"
},

Para uma saída mais sofisticada durante o desenvolvimento npm install --global snazzye execute-a em vez denpm test .

Nota: Verificação de tipo versus heurística

Meu amigo, ao mencionar o espaço de design, se refere a Elm, e eu o encorajo a experimentar esse idioma.

Por quê? O JS é de fato inspirado no LISP, que é uma classe especial de linguagens, que por acaso não está tipada . Linguagens como Elm ou Purescript são linguagens de programação funcional digitadas .

Digite restringir sua liberdade para que o compilador possa verificar e guiá-lo quando você violar o idioma ou as regras do seu próprio programa; independentemente do tamanho (LOC) do seu programa.

Recentemente, um colega júnior implementou uma interface reativa duas vezes: uma vez em Elm, outra em React; dê uma olhada para ter uma idéia do que estou falando.

Comparar Main.elm(digitado) ⇔ index.js(sem tipo, sem testes)

(ps. observe que o código React não é idiomático e pode ser melhorado)

Uma observação final,

a realidade é que JS não é digitado. Quem sou eu para sugerir a programação digitada para você?

Veja, com JS, estamos em um domínio diferente: livres de tipos, podemos facilmente expressar coisas difíceis ou impossíveis de fornecer um tipo adequado (o que certamente pode ser uma vantagem).

Porém, sem tipos, há pouco para manter nossos programas sob controle, portanto somos forçados a apresentar testes e (em menor extensão) estilos de código.

Eu recomendo que você procure no LISP (por exemplo, ClojureScript ) para obter inspiração e invista no teste de seus códigos. Leia O caminho da sub-embalagem - para ter uma idéia.

Paz.


Por que o voto negativo? Certamente não me importo, mas como o OP escreveu "está me ajudando a escrever um JavaScript melhor", acho que essa é uma resposta útil? O que você acha?
fios

1
não relacionados com os downvotes, mas ambos os seus links Main.elm e index.js são 404s
CS01

1
A questão era claramente jslint ou jshint, não pedindo alternativas.
precisa saber é o seguinte

1
O gif merece um voto positivo.
precisa saber é

8

Bem, em vez de fazer configurações manuais de cotão, podemos incluir todas as configurações de cotão no topo do arquivo JS, por exemplo,

Declare toda a var global nesse arquivo como:

/*global require,dojo,dojoConfig,alert */

Declare todas as configurações de cotão como:

/*jslint browser:true,sloppy:true,nomen:true,unparam:true,plusplus:true,indent:4 */

Espero que isso ajude você :)


1

Há também outra alternativa desenvolvida ativamente - JSCS - JavaScript Code Style :

O JSCS é um ponteiro de estilo de código para aplicar programaticamente seu guia de estilo. Você pode configurar o JSCS para seu projeto em detalhes usando mais de 150 regras de validação, incluindo predefinições de guias de estilo populares como jQuery, Airbnb, Google e muito mais.

Ele vem com vários pré-ajustes que você pode escolher entre simplesmente especificando o presetno .jscsrcarquivo de configuração e personalize - override, habilitar ou desabilitar todas as regras:

{
    "preset": "jquery",
    "requireCurlyBraces": null
}

Também existem plugins e extensões criados para editores populares.

Veja também:

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.