Comment utiliser les fonctions anonymes JS

Cette fois, je vais vous expliquer comment utiliser lesfonctions anonymes de JS et quelles sont les précautions lors de l'utilisation des fonctions anonymes de JS. Voici des cas pratiques. .

La forme de base d'une fonction anonyme est (function(){...})();

La première parenthèse contient le corps de la fonction, et la parenthèse suivante sert à transmettre les paramètres à la fonction anonyme et à l'exécuter immédiatement

Le but des fonctions anonymes est d'éviter la pollution des variables globales et les conflits de noms de fonctions

Chaque fois que vous lisez du code, vous devez être conscient des fonctions anonymes. Parfois on les appelle des lambdas, parfois des fonctions anonymes, de toute façon je pense qu'elles sont difficiles à utiliser.

Si vous ne savez pas ce qu'est une fonction anonyme, voici une citation :

Une fonction anonyme est une fonction déclarée dynamiquement au moment de l'exécution. On les appelle fonctions anonymes car contrairement aux fonctions ordinaires, elles n’ont pas de nom de fonction. — Helen Emerson, Helenphant.com

La fonction anonyme a la forme suivante :

function () { ... code ... }
OR
(args) => { ... code .. }

Aujourd'hui j'essaie de vous faire comprendre l'idée d'utiliser les fonctions anonymes en général uniquement lorsque cela est absolument nécessaire. Les fonctions anonymes ne doivent pas être privilégiées et ne doivent être utilisées que si les raisons sont connues. Lorsque vous comprendrez cette idée, votre code deviendra plus propre, plus facile à maintenir et plus facile à suivre les bogues. Commençons par trois raisons d'éviter d'utiliser les fonctions anonymes :

Lorsque vous écrivez du code, même si vous êtes doué pour taper du code, vous rencontrerez toujours des erreurs. Parfois ces erreurs sont faciles à détecter, parfois non.

Les erreurs peuvent être facilement détectées si vous savez d’où elles viennent. Pour trouver les erreurs, nous utilisons cet outil appelé stack trace. Si vous ne connaissez pas les traces de pile, Google propose une excellente introduction.

Supposons que nous ayons un projet très simple :

function start () {
 (function middle () {
 (function end () {
  console.lg('test');
 })()
 })()
}

Il y a une erreur très stupide dans le code ci-dessus, une faute de frappe (console.log). Dans un petit projet, cette faute d’orthographe n’est pas un gros problème. S’il s’agit d’une petite partie d’un très grand projet comportant de nombreux modules, le problème est énorme. En supposant que vous n'ayez pas commis cette erreur stupide, le nouvel ingénieur junior la validera dans la base de code avant de partir en vacances !

Il faut maintenant aller au fond des choses. En utilisant notre fonction soigneusement nommée, nous obtenons une trace de pile comme celle-ci :

Merci d'avoir nommé vos fonctions, développeurs juniors ! Nous pouvons désormais facilement localiser le bug.

Mais... une fois que nous avons corrigé ce problème, nous avons découvert qu'il y avait un autre bug. Cette fois, il a été introduit par un développeur plus expérimenté. Cette personne connaît les lambdas
Il s'avère qu'elle tombe sur un bug et c'est notre travail de le retrouver.

Voici le code :

(function () {
 (function () {
 (function () {
  console.lg('test');
 })();
 })();
})();

Sans surprise, ce développeur a également oublié comment épeler console.log ! C'est trop une coïncidence ! C'est dommage qu'aucun d'entre eux n'ait nommé ses fonctions.

Alors, que va sortir la console ?

Eh bien, nous avons au moins encore des numéros de ligne, n'est-ce pas ? Dans cet exemple, il semble que nous ayons environ 7 lignes de code. Que se passe-t-il si nous traitons d’un gros bloc de code ? Comme dix mille lignes de code ? Que devons-nous faire si l’étendue des numéros de ligne est si grande ? S'il existe un fichier codemap une fois le code plié, le rendu des numéros de ligne est-il inutile du tout ?

Je pense que la réponse à ces questions est assez simple. La réponse est : penser à ces choses rendra votre journée assez misérable.

Lisibilité

Hé, j'ai entendu dire que tu n'y crois toujours pas. Vous êtes toujours attaché à votre fonction anonyme, et le bug n'est jamais survenu. Eh bien, je dois vous présenter mes excuses de penser que votre code est parfait. Jetons un coup d'œil à cela !

Jetez un œil aux deux morceaux de code suivants :

function initiate (arguments) {
 return new Promise((resolve, reject) => {
 try {
  if (arguments) {
   return resolve(true);
  }
  return resolve(false);
 } catch (e) {
  reject(e);
 }
 });
}
initiate(true)
 .then(res => {
  if (res) {
   doSomethingElse();
  } else {
   doSomething();
  }
 ).catch(e => {
   logError(e.message);
   restartApp();
   }
 );

C'est un exemple très inhabituel, mais je pense que vous comprenez ce que je vais dire. Notre méthode renvoie une promesse, et nous utilisons cette méthode promiseObject/ pour gérer différentes réponses possibles.

Vous pourriez penser que ces quelques morceaux de code ne sont pas difficiles à lire, mais je pense qu’ils peuvent être meilleurs !

Que se passerait-il si nous supprimions toutes les fonctions anonymes ?

function initiate (arguments) {
 return new Promise(checkForArguments);
}
function checkForArguments (resolve, reject) {
 try {
 if (arguments) {
  return resolve(true); 
 }
 return resolve(false);
 } catch (e) {
 reject(e);
 }
}
function evaluateRes (res) {
 if (res) {
 doSomethingElse();
 } else {
 doSomething();
 }
}
function handleError (e) {
 logError(e.message);
 restartApp();
}
initiate(true)
 .then(evaluateRes)
 .catch(handleError);

好，先讲清楚：这部分代码更长，但我认为其不仅仅是有更多的可读性！我们精心命名的函数与匿名函数不一样，只要我们一看到它们的名字就知道它们的功能是什么。这避免了在评估代码时的障碍。

这也有助于分清楚其中的关系。与创建一个方法、将其传递、然后运行逻辑不同，在第二个例子中的参数被给到了then，catch只是指向了发生所有事情的函数。

关于更具有可读性，我没有什么再能说服你的了。但是也许你还没被说服的话，我可以试一下最后的论据。

相信看了本文案例你已经掌握了方法，更多精彩请关注php中文网其它相关文章！

推荐阅读：

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!