Qual é a convenção de JavaScript para nenhuma operação? Como um passcomando Python .

• Uma opção é simplesmente uma função vazia: function() {}
• jQuery oferece $.noop(), que simplesmente chama a função vazia acima.
• É aceitável simplesmente inserir um valor de falseou 0?

No contexto ... tudo isso funciona sem gerar um erro no Chrome:

var a = 2;
(a === 1) ? alert(1) : function() {};
(a === 1) ? alert(1) : $.noop();
(a === 1) ? alert(1) : false;
(a === 1) ? alert(1) : 0;

EDIT: Muitas pessoas responderam com: "não faça isso! Mude a estrutura do código!" Isso me lembra de uma postagem em que alguém perguntou como farejar o navegador. Ele recebeu uma enxurrada de postagens dizendo: "NÃO FAÇA ISSO! É MAL", mas ninguém lhe disse como farejar o navegador . Esta não é uma revisão de código. Imagine que você esteja lidando com um código legado que não pode ser alterado e, sem alguma função transmitida, ele apresentará um erro. Ou, simplesmente, é assim que o cliente deseja e está me pagando . Portanto, respeitosamente, responda à pergunta : Qual é a melhor maneira de especificar uma função "sem operação" em JavaScript?

EDIT2: Que tal um desses?

true;
false;
0;
1;
null;

Para responder à pergunta original, a implementação mais elegante e organizada de uma função noop em Javascript puro (como também é discutido aqui ) é Function.prototype . Isto é porque:

1. Function.prototype é uma função:

typeof Function.prototype === "function" // returns true

2. Ele pode ser chamado como uma função e essencialmente não faz nada conforme mostrado aqui:

setTimeout(function() {
      console.log('Start: ', Date.now());
      Function.prototype();
      console.log('End  : ', Date.now());
    }, 1000);

Embora este seja um "noop verdadeiro", uma vez que a maioria dos navegadores parece não fazer nada para executar o noop definido desta forma (e, portanto, salvar os ciclos da CPU), pode haver alguns problemas de desempenho associados a isso (como também é mencionado por outros em comentários ou em outras respostas).

No entanto, dito isso, você pode definir facilmente sua própria função noop e, de fato, muitas bibliotecas e estruturas também fornecem funções noop. Abaixo estão alguns exemplos:

var noop = function () {};           // Define your own noop in ES3 or ES5
const noop = () => {};               // Define in ES6 as Lambda (arrow function)
setTimeout(noop, 10000);             // Using the predefined noop

setTimeout(function () {} , 10000);  // Using directly in ES3 or ES5
setTimeout(() => {} , 10000);        // Using directly in ES6 as Lambda (arrow function)

setTimeout(angular.noop, 10000);     // Using with AngularJS 1.x
setTimeout(jQuery.noop, 10000);      // Using with jQuery

Aqui está uma lista em ordem alfabética de várias implementações de funções noop (ou discussões relacionadas ou pesquisas no Google):

AngularJS 1.x , Angular 2+ (não parece ter uma implementação nativa - use a sua própria como mostrado acima), Ember , jQuery , Lodash , NodeJS , Ramda , React (não parece ter uma implementação nativa - use a sua como mostrado acima), RxJS , sublinhado

CONCLUSÃO : Embora Function.prototype seja uma maneira elegante de expressar um noop em Javascript, no entanto, pode haver alguns problemas de desempenho relacionados ao seu uso. Portanto, você pode definir e usar o seu próprio (como mostrado acima) ou usar um definido pela biblioteca / estrutura que você pode estar usando em seu código.

O mais concisa e noop performance é uma função seta vazia : ()=>{}.

As funções de seta funcionam nativamente em todos os navegadores, exceto no IE (há uma transformação babel, se necessário):

()=>{} vs. Function.Prototype

• ()=>{}é 87% mais rápido do que Function.prototypeno Chrome 67.
• ()=>{}é 25% mais rápido do que Function.prototypeno Firefox 60.
• ()=>{}é 85% mais rápido do que Function.prototypeno Edge (15/06/2018) .
• ()=>{}é 65% menos código do que Function.prototype.

O teste abaixo esquenta usando a função de seta para dar um viés Function.prototype, mas a função de seta é a vencedora:

const noop = ()=>{};
const noopProto = Function.prototype;

function test (_noop, iterations) {
    const before = performance.now();
    for(let i = 0; i < iterations; i++) _noop();
    const after = performance.now();
    const elapsed = after - before;
    console.info(`${elapsed.toFixed(4)}MS\t${_noop.toString().replace('\n', '')}\tISNOOP? ${_noop() === undefined}`);
    return elapsed;
}

const iterations = 10000000
console.info(`noop time for ${iterations.toLocaleString()} iterations`)
const timings = {
    noop: test(noop, iterations),
    noopProto: test(noopProto, iterations)
}

const percentFaster = ((timings.noopProto - timings.noop)/timings.noopProto).toLocaleString("en-us", { style: "percent" });
console.info(`()=>{} is ${percentFaster} faster than Function.prototype in the current browser!`)

tudo o que você tende a conseguir aqui está errado. As expressões ternárias não devem ser usadas como uma declaração completa, apenas na expressão, portanto, a resposta à sua pergunta é:

nenhuma de suas sugestões, em vez disso:

var a = 2;
if (a === 1)
    alert(1)
// else do nothing!

então o código é facilmente compreensível, legível e tão eficiente quanto possível.

Por que tornar mais difícil, quando pode ser simples?

editar:

Então, um comando de "não operação" indica basicamente uma estrutura de código inferior?

Você está perdendo o meu ponto. Tudo o que foi dito acima é sobre a expressão ternária x ? y : z.

Porém, um comando no operation não faz sentido em linguagens de nível superior, como Javascript.

Geralmente é usado, em linguagens de nível inferior, como assembly ou C, como uma maneira de fazer o processador não fazer nada por uma instrução para fins de temporização.

Em JS, se você faz 0;, null;, function () {};ou uma declaração vazia, há grandes chances de que ele será ignorado pelo intérprete quando ele é lê-lo, mas antes que ele obtém interpretado, assim, no final, você só vai fazer o seu programa ser carregado mais lentamente por um período de tempo muito pequeno. Nota Bene : Estou supondo isso, pois não estou envolvido em nenhum interpretador JS amplamente usado e há chances de cada interpretador ter sua própria estratégia.

No caso de você usar algo um pouco mais complicado, como $.noop()ou var foo = function () {}; foo(), então o interpretador pode fazer uma chamada de função inútil que acabará estragando alguns bytes de sua pilha de funções e alguns ciclos.

A única razão pela qual vejo uma função como $.noop()existiria seria para ainda ser capaz de fornecer uma função de retorno de chamada para alguma função de evento que lançaria uma exceção se não pudesse chamar esse retorno de chamada. Mas então, é necessariamente uma função que você precisa fornecer, e dar a ela o noopnome é uma boa ideia, então você está dizendo aos seus leitores (e isso pode ser você em 6 meses) que você atribuiu uma função vazia de propósito.

No final das contas, não existe estrutura de código "inferior" ou "superior". Você está certo ou errado na maneira como usa suas ferramentas. Usar um ternário como exemplo é como usar um martelo para aparafusar. Vai funcionar, mas você não tem certeza de que pode pendurar algo nesse parafuso.

O que pode ser considerado "inferior" ou "superior" é o algoritmo e as ideias que você colocou em seu código. Mas isso é outra coisa.

Acho que o noop()objetivo principal do jQuery é impedir o código de travar, fornecendo uma função padrão quando a solicitada não está disponível. Por exemplo, considerando o seguinte exemplo de código, $.noopé escolhido se fakeFunctionnão estiver definido, evitando que a próxima chamada para fntravar:

var fn = fakeFunction || $.noop;
fn() // no crash

Em seguida, noop()permite economizar memória evitando escrever a mesma função vazia várias vezes em todo o código. A propósito, $.noopé um pouco menor que function(){}(6 bytes salvos por token). Portanto, não há relacionamento entre o seu código e o padrão de função vazio. Use null, falseou 0se quiser, no seu caso não haverá efeito colateral. Além disso, é importante notar que este código ...

true/false ? alert('boo') : function(){};

... é completamente inútil já que você nunca chamará a função, e esta ...

true/false ? alert('boo') : $.noop();

... é ainda mais inútil, pois você chama uma função vazia, que é exatamente o mesmo que ...

true/false ? alert('boo') : undefined;

Vamos substituir a expressão ternária por uma ifdeclaração para ver o quanto é inútil:

if (true/false) {
    alert('boo');
} else {
    $.noop(); // returns undefined which goes nowhere
}

Você pode simplesmente escrever:

if (true/false) alert('boo');

Ou ainda mais curto:

true/false && alert('boo');

Para finalmente responder à sua pergunta, acho que "nenhuma operação convencional" é aquela que nunca é escrita.

Eu uso:

 (0); // nop

Para testar o tempo de execução desta execução como:

console.time("mark");
(0); // nop
console.timeEnd("mark");

resultado: marca: 0,000ms

O uso Boolean( 10 > 9)pode ser reduzido a simplesmente o ( 10 > 9)que retorna true. Tendo a ideia de usar um único operando que eu esperava totalmente, (0);ele retornaria false, mas ele simplesmente retorna o argumento, conforme pode ser revisado executando este teste no console.

> var a = (0);
< undefined
> a
< 0

Não há absolutamente nenhum problema ou desempenho penalidade de usar Function.prototypemais () => {}.

O principal benefício Function.prototypeé ter uma função singleton em vez de redefinir uma nova função anônima a cada vez. É especialmente importante usar um Function.prototypeambiente autônomo ao definir valores padrão e memoizing, pois ele fornece um ponteiro de objeto consistente que nunca muda.

O motivo pelo qual estou recomendando, Function.prototypee não Functionporque eles não são iguais:

Function() === Function()
// false

Function.prototype() === Function.prototype()
// true

Além disso, os benchmarks de outras respostas são enganosos . Na verdade, tem um Function.prototypedesempenho mais rápido do que () => {}dependendo de como você escreve e executa o benchmark:

Você não pode confiar nos benchmarks JS << Referindo especificamente os benchmarks nesta questão.

Não estilize seu código a partir de benchmarks; faça tudo o que for passível de manutenção e deixe o interpretador descobrir como otimizar a longo prazo.