Jshint: Os parâmetros regulares não devem vir após os parâmetros padrão

Esta mensagem foi implementada originalmente como um "erro" JSHint (o que significa que poderia
não ser ignorado): gh-1779. Embora possa ter sido um SyntaxError em alguns dos primeiros
rascunho, não foi finalizado dessa forma, então em gh-2543, nós "rebaixamos" o
mensagem a um aviso. Isso significa que você _pode_ ignorá-lo no JSHint 2.9.1 via
-W138 .

Dito isso, ainda não está claro se esse aviso é apropriado. eu
pessoalmente acho que as funções projetadas desta forma são difíceis de usar, mas
Não consigo identificar nenhum problema potencial de segurança do código.

@rwaldron @caitp Algum de vocês tem alguma opinião sobre isso?

Só quero mencionar que esse tipo de assinatura faz parte dos exemplos de código redux. Procure a linha:

function counter(state = 0, action) {

então, é amplamente utilizado, IMHO.

Este tipo de padrão é _absolutamente_ a definição de "lint".

então, é amplamente utilizado, IMHO.

Eu discordo veementemente com a implicação de que um padrão que aparece em redux é indicativo de algo "amplamente utilizado". Eu olhei pelo redux e encontrei exemplos de counter(undefined, action) e fiquei imaginando qual seria o objetivo disso, considerando que cada um deles realmente _requer_ o argumento action , ou enfrente um tempo de execução erro. Se action é _sempre_ obrigatório e state é opcional, por que exigir chamadas que devem passar explicitamente undefined - isso vai contra o propósito dos valores de parâmetro padrão .

... Estou tentado a registrar um bug.

Dito isso, ainda não está claro se esse aviso é apropriado.

Acredito que sim, e qualquer pessoa que não queira o aviso pode desativá-lo.

Sinta-se à vontade para fechar este @jugglinmike

@rwaldron ok, na verdade não discutimos redux. Você pode fornecer um exemplo de erro que pode aparecer com essa assinatura?
Para mim, é apenas uma propriedade da linguagem. Então, qual é a razão para marcá-lo como "errado"?

Você pode fornecer um exemplo de erro que pode aparecer com essa assinatura?

O único erro de tempo de execução que você encontrará está chamando como: counter() e counter(undefined) , mas esse não é o meu ponto. O que quero dizer é que esse design é terrível e coloca uma carga excessiva no programador e em suas ferramentas. Por exemplo, um minificador poderia analisar razoavelmente o seguinte:

function counter(action, state = 0) {
  return [action, state];
}
counter({});
counter({}, 0);
counter({}, undefined);

E produzir:

function c(a,s=0){return[a,s]}
c({});
c({});
c({});

Considerando que, colocando o padrão primeiro:

function counter(state = 0, action) {
  return [state, action];
}
counter(0, {});
counter(undefined, {});

produziria:

function c(s=0,a){return[s,a]}
c(0, {});
c(undefined, {});

Este é um exemplo bastante artificial, mas ainda ilustra meu ponto de que torna o uso de um parâmetro padrão completamente e totalmente inútil.

Para mim, é apenas uma propriedade da linguagem.

Só porque você pode, não significa que você deva.

Então, no momento você não consegue explicar porque é um design ruim, exceto se preocupar com bugs em minificadores

Exigir que todos os sites de chamada passem um undefined explícito, para evitar uma assinatura de chamada mal projetada, é considerado uma prática ruim e um uso incorreto de parâmetros padrão.

Este comportamento é incentivado pelo React / Redux. É mais provável que eu remova jshint do que React / Redux: /

http://redux.js.org/docs/basics/Reducers.html

Um truque interessante é usar a sintaxe de argumentos padrão do ES6 para escrever isso de uma forma mais compacta:

function todoApp (state = initialState, action) {
// Por enquanto, não lide com nenhuma ação
// e apenas retornar o estado que nos foi dado.
estado de retorno
}

@jugglinmike wdyt ^^?

@txm o que acontece com o parâmetro action que nunca foi usado?

Ainda sou da opinião que, na ausência de um perigo tangível (e mesmo em
presença de padrões indesejáveis), JSHint deve permanecer em silêncio.
Dito isso, estou tendo problemas para entender como o exemplo de @txm é diferente.

Como posso desativá-lo ..?

@thalesfsp : Adicione /* jshint -W138 */ adicione o início do seu arquivo. (Certifique-se de usar o jshint v2.9.1 ou mais recente)

Tropecei no mesmo problema com Redux. Isso pode ser desabilitado no arquivo de configuração .jshintrc, por favor?

@derwaldgeist Claro! Aqui está um exemplo de arquivo .jshintrc que silencia o aviso:

{
  "esversion": 6,
  "-W138": true
}

(A propósito, a documentação do JSHint contém mais informações sobre como desabilitar avisos específicos.)

@jugglinmike Obrigado. Não sabia que também era possível usar a sintaxe "-Wxxx" no arquivo .jshintrc. Sempre usei isso no início de um arquivo. Ótimo saber!

Com 'callback' sendo amplamente usado como o último parâmetro de uma função, este aviso de lint parece um tanto bobo para mim

openDialog (url, nome, args = {}, pos) {
retornar uma nova promessa (função (resolver, rejeitar) {
chrome.windows.create ({
url: url,
tipo: "pop-up",
largura: pos && pos.width || Indefinido,
altura: pos && pos.height || Indefinido,
esquerda: pos && pos.left || Indefinido,
topo: pos && pos.top || Indefinido
}, função (w) {

Aparentemente, padronizar os outros parâmetros para undefined é válido e passa no processo de linting. Não estou dizendo que esse é um padrão melhor, mas ele passa no processo de linting.