Explicação da quebra de linha incorreta do JSHint antes do erro '+'


125

Alguém pode me explicar por que o JSHint reclama do seguinte,

window.location.href = String1
    + '#'
    + Sting2
    + '='
    + String3;

Com o erro, Bad line breaking before '+' error

Entendo que esse erro pode ser configurado com a laxbreak opção , descrita como

Esta opção suprime a maioria dos avisos sobre possíveis quebras de linha não seguras no seu código. Não suprime avisos sobre o estilo de codificação por vírgula. Para suprimir aqueles que você precisa usar laxcomma (veja abaixo).

Essa explicação é bem concisa e estou curioso para saber por que quebrar linhas dessa maneira é considerado ruim ou negligente em primeiro lugar.

Lembre-se de que não estou tentando iniciar uma guerra santa aqui, estou apenas procurando uma resposta objetiva sobre por que as pessoas do JSHint pensam que isso é ruim, se é apenas uma preferência de estilo que eles estão injetando em seu circuito (eu pensei que o JSLint era o ponteiro opinativo) ou se houver algo que pode dar errado em certos intérpretes ao quebrar a linha dessa maneira.


6
Eu acho que é apenas "estilo ruim", de acordo com o JSHint. Você obteria o mesmo efeito se usar vírgulas à esquerda. Para facilitar a leitura, eu pelo menos reescrevi com o + no final da linha.
Iwan

28
Vadio. Eu acho que esse estilo é absolutamente o estilo mais legível para usar com strings de várias linhas, especialmente ao visualizar o código em uma janela estreita.
Lambart 28/07

12
liderar com tokens que continuam a instrução ajuda a alinhar as coisas e expressar visualmente a continuação na parte esquerda do bloco de código, onde é de esperar encontrar os elementos estruturais, especialmente se estiver digitalizando rapidamente. É definitivamente viável e razoável, e não, objetivamente, estilo ruim. Há, no entanto, um problema de integridade do código para impor essa regra, o que é lamentável.
precisa

1
@AdamTolley Concordo plenamente, e quando perguntei sobre isso, recebi o que parecia ser a confirmação de que era FUD. Foi submetido a um exame minucioso após o "efeito meta"; e esse exame parecia confirmar que isso é viável e razoável.
HostileFork diz que não confia em SE

2
Atualmente ( JSHint 2.9.4 ) a mensagem de erro é quebra de linha enganosa antes de '+'; os leitores podem interpretar isso como um limite de expressão.
RhinoDevel 17/17/17

Respostas:


107

É um guia de estilo para evitar declarações que possam estar sujeitas a suposições sobre a inserção automática de ponto e vírgula .

A idéia é que você deixe claro, no final de uma linha, se a expressão termina aí ou pode continuar na próxima linha.


6
Obrigado pela resposta, ter uma justificativa por trás do erro torna muito mais fácil justificar as alterações para apaziguar o JSHint.
James McMahon

36
A inserção automática de ponto e vírgula é um racional razoável para esse estilo ser imposto. Mas quando a expressão está entre parênteses, o aviso persiste. E isso me deixa triste.
Ben Hyde

23
segundo @BenHyde e, em geral, é mais legível para humanos ao percorrer o código para liderar a linha com a +. é mais fácil para os olhos (e menos propenso a erros) seguir uma única coluna à esquerda do que pular para o final de cada linha para ver se ela será anexada à próxima linha. até a gramática é menos desajeitada: "a linha 118 acrescenta 117" versus "a linha 117 será anexada pela linha 118".
worc

9
Pessoalmente, eu odeio anexar operadores (e vírgulas) ao final das linhas porque passo rapidamente por ele. É mais fácil para mim ler a lógica nas instruções booleanas de várias linhas (&& ou || no início de uma linha em vez de no final), e posso distinguir rapidamente as listas delimitadas por vírgulas além de outras instruções de várias linhas iniciando-as com um vírgula. Graças a Deus por laxbreak
aaaaaa

2
@ Barney Como você reconcilia a preocupação com a inserção automática de ponto e vírgula com as respostas dadas à minha pergunta muito semelhante ? Qual é o risco justificável desse formato? Para mim, ele tem uma vantagem na digitalização.
HostileFork diz que não confia no SE

8

Jshint não sinalizará isso como uma quebra de linha incorreta se você usar o + antes da quebra de linha, em oposição à nova linha. Igual a:

window.location.href = String1 +
'#' +
Sting2 +
'=' +
String3;

10
Isso não responde à pergunta nem um pouquinho. Por que tantos votos positivos?
Lambart

4
Talvez, mas essa seja uma maneira de solucionar esse problema sem precisar alterar as configurações do jshint.
precisa saber é o seguinte

4
Este deve ser um comentário, pois não responde realmente à pergunta, mas fornece informações valiosas.
tomtomssi

3

Não é uma resposta direta à pergunta, mas para quem se deparar com isso no Google (como eu fiz) que deseja manter a regra e corrigir os avisos, o seguinte pode ser útil ...

Ao usar o Notepad ++ (por exemplo, com o plugin JSLint), isso pode ser corrigido usando a seguinte pesquisa e substituição:

  • Encontre o que: (\r\n|\n|\r)( *)\+
  • Substitua por: (incluindo o primeiro e o último espaço) +$1$2 
  • Modo de Pesquisa: Expressão regular

(Apenas testado no Windows, mas o regex também deve funcionar com as terminações de linha Unix ou Mac OS.)

Para fazer uma coisa semelhante para ||, &&, ==, !=, <=ou >=em vez de +, use o seguinte:

  • Encontre o que: (\r\n|\n|\r)( *)(\|\||&&|==|!=|<=|>=)
  • Substitua por: (incluindo o primeiro e o último espaço) $3$1 $2 

5
Útil, talvez, para pessoas que desejam alterar sua formatação. Mas falha completamente em responder à pergunta (implícita): "Estou curioso sobre por que quebrar linhas dessa maneira é considerado ruim ou negligente em primeiro lugar".
Lambart

Ponto justo, adicionei uma nota no topo explicando por que eu postei isso.
Steve Chambers
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.