Qual è la convenzione JavaScript per nessuna operazione? Come un passcomando Python .

• Un'opzione è semplicemente una funzione vuota: function() {}
• offre jQuery $.noop(), che chiama semplicemente la funzione vuota sopra.
• È accettabile inserire semplicemente un valore di falseo 0?

Nel contesto ... tutti questi funzionano senza generare errori in 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: molte persone hanno risposto con "non farlo! Cambia la struttura del codice!" Questo mi ricorda un post in cui qualcuno chiedeva come annusare il browser. Ha ricevuto una raffica di messaggi che dicevano: "NON FARLO! È MALE", ma nessuno gli ha detto come annusare il browser . Questa non è una revisione del codice. Immagina di avere a che fare con codice legacy che non può essere modificato e senza che venga passata alcuna funzione, verrà generato un errore. O, semplicemente, è così che il cliente vuole e mi paga . Quindi, rispettosamente, rispondi alla domanda : qual è il modo migliore per specificare una funzione "nessuna operazione" in JavaScript?

EDIT2: Che ne dici di uno di questi?

true;
false;
0;
1;
null;

Per rispondere alla domanda originale, l'implementazione più elegante e ordinata di una funzione noop in puro Javascript (come discusso anche qui ) è Function.prototype . Questo è perché:

1. Function.prototype è una funzione:

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

2. Può essere richiamato come funzione e essenzialmente non fa nulla come mostrato qui:

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

Sebbene questo sia un "vero noop" poiché la maggior parte dei browser sembra non fare nulla per eseguire il noop definito in questo modo (e quindi salvare i cicli della CPU), potrebbero esserci alcuni problemi di prestazioni associati a questo (come menzionato anche da altri nei commenti o in altre risposte).

Tuttavia, detto questo, puoi facilmente definire la tua funzione noop e, infatti, molte librerie e framework forniscono anche funzioni noop. Di seguito sono riportati alcuni esempi:

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

Ecco un elenco alfabetico di varie implementazioni di funzioni noop (o discussioni correlate o ricerche su Google):

AngularJS 1.x , Angular 2+ (non sembra avere un'implementazione nativa - usa la tua come mostrato sopra), Ember , jQuery , Lodash , NodeJS , Ramda , React (non sembra avere un'implementazione nativa - usa la tua come mostrato sopra), RxJS , Underscore

LINEA DI FONDO : sebbene Function.prototype sia un modo elegante per esprimere un noop in Javascript, tuttavia, potrebbero esserci alcuni problemi di prestazioni legati al suo utilizzo. Quindi, puoi definire e utilizzare il tuo (come mostrato sopra) o usarne uno definito dalla libreria / framework che potresti utilizzare nel tuo codice.

Più conciso e noop performante è una funzione freccia vuota : ()=>{}.

Le funzioni Arrow funzionano in modo nativo in tutti i browser tranne IE (c'è una trasformazione babel se necessario):

()=>{} vs. Function.Prototype

• ()=>{}è l' 87% più veloce rispetto Function.prototypea Chrome 67.
• ()=>{}è del 25% più veloce rispetto Function.prototypea Firefox 60.
• ()=>{}è dell'85% più veloce rispetto Function.prototypea Edge (15/6/2018) .
• ()=>{}è il 65% in meno di codice rispetto a Function.prototype.

Il test seguente si riscalda utilizzando la funzione freccia per dare un bias Function.prototype, ma la funzione freccia è il chiaro vincitore:

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!`)

tutto ciò che tendi a ottenere qui è sbagliato. Le espressioni ternarie non devono essere utilizzate come una dichiarazione completa, solo nell'espressione, quindi la risposta alla tua domanda è:

nessuno dei tuoi suggerimenti, invece:

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

quindi il codice è facilmente comprensibile, leggibile e quanto più efficiente possibile.

Perché renderlo più difficile, quando può essere semplice?

modificare:

Quindi, un comando "nessuna operazione" indica fondamentalmente una struttura di codice inferiore?

Stai perdendo il mio punto. Tutto quanto sopra riguarda l'espressione ternaria x ? y : z.

Tuttavia, un comando senza operazione non ha senso in linguaggi di livello superiore come Javascript.

Di solito è usato, in linguaggi di livello inferiore come assembly o C, come un modo per fare in modo che il processore non faccia nulla per un'istruzione per scopi di temporizzazione.

In JS, se fare 0;, null;, function () {};o una dichiarazione di vuoto, ci sono grandi possibilità che esso sarà ignorato dal interprete quando si sta leggendo, ma prima che venga interpretata, quindi alla fine, devi semplicemente rendere il vostro programma di essere caricati più lentamente per un tempo davvero minimo. Nota Bene : lo presumo, poiché non sono coinvolto in alcun interprete JS ampiamente utilizzato e ci sono possibilità che ogni interprete abbia la propria strategia.

Nel caso in cui usi qualcosa di un po 'più complicato, come $.noop()o var foo = function () {}; foo(), l'interprete potrebbe eseguire una chiamata di funzione inutile che finirà per rovinare alcuni byte del tuo stack di funzioni e alcuni cicli.

L'unico motivo per cui vedo una funzione come $.noop()potrebbe esistere, sarebbe essere in grado di dare ancora una funzione di callback a qualche funzione di evento che genererebbe un'eccezione se non può chiamare quella callback. Ma poi, è necessariamente una funzione che devi dare, e dargli il noopnome è una buona idea, quindi stai dicendo ai tuoi lettori (e potresti essere tu tra 6 mesi) che dai di proposito una funzione vuota.

Alla fine, non esiste una struttura del codice "inferiore" o "superiore". Hai ragione o torto nel modo in cui usi i tuoi strumenti. Usare un ternario per il tuo esempio è come usare un martello quando vuoi avvitare. Funzionerà, ma non sei sicuro di poter appendere qualcosa a quella vite.

Ciò che potrebbe essere considerato "inferiore" o "superiore" è l'algoritmo e le idee che inserisci nel codice. Ma questa è un'altra cosa.

Penso che jQuery noop()sia principalmente inteso a prevenire il crash del codice fornendo una funzione predefinita quando quella richiesta non è disponibile. Ad esempio, considerando il seguente esempio di codice, $.noopviene scelto se fakeFunctionnon è definito, impedendo l' fnarresto anomalo della chiamata successiva a :

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

Quindi, noop()consente di risparmiare memoria evitando di scrivere la stessa funzione vuota più volte ovunque nel codice. A proposito, $.noopè un po 'più corto di function(){}(6 byte salvati per token). Quindi, non esiste alcuna relazione tra il codice e il modello di funzione vuoto. Usa null, falseo 0se vuoi, nel tuo caso non ci saranno effetti collaterali. Inoltre, vale la pena notare che questo codice ...

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

... è completamente inutile dato che non chiamerai mai la funzione, e questa ...

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

... è ancora più inutile dato che chiami una funzione vuota, che è esattamente la stessa di ...

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

Sostituiamo l'espressione ternaria con ifun'affermazione per vedere quanto è inutile:

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

Potresti semplicemente scrivere:

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

O anche più breve:

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

Per rispondere finalmente alla tua domanda, immagino che una "operazione non convenzionale" sia quella che non viene mai scritta.

Io uso:

 (0); // nop

Per testare il tempo di esecuzione di questa esecuzione come:

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

risultato: voto: 0.000ms

L'utilizzo Boolean( 10 > 9)può essere ridotto a semplicemente ( 10 > 9)che ritorna true. Venendo all'idea di usare un singolo operando, mi aspettavo che (0);sarebbe tornato false, ma restituisce semplicemente l'argomento come può essere rivisto eseguendo questo test sulla console.

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

Non c'è assolutamente alcun problema o penalizzazione delle prestazioni dell'utilizzo di Function.prototypeover () => {}.

Il vantaggio principale di Function.prototypeè avere una funzione singleton piuttosto che ridefinire ogni volta una nuova funzione anonima. È particolarmente importante utilizzare una no-op come Function.prototypequando si definiscono i valori predefiniti e si memorizza in quanto fornisce un puntatore a un oggetto coerente che non cambia mai.

Il motivo per cui raccomando Function.prototypepiuttosto che Functionè perché non sono la stessa cosa:

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

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

Inoltre, i benchmark di altre risposte sono fuorvianti . In effetti, Function.prototypefunziona più velocemente che a () => {}seconda di come scrivi ed esegui il benchmark:

Non ci si può fidare dei benchmark JS << Chiamando specificatamente benchmark su questa domanda.

Non applicare lo stile al codice dai benchmark; fare tutto ciò che è gestibile e lasciare che l'interprete capisca come ottimizzare a lungo termine.