Pourquoi ne pas utiliser les fonctions anonymes JS

Cet article analyse principalement les trois principales raisons de ne pas utiliser les fonctions anonymes de js. Le rôle des fonctions anonymes est d'éviter la pollution des variables globales et les conflits de noms de fonctions. Veuillez vous référer à cet article pour les trois raisons principales de js anonyme. fonctions. J'espère que vous pourrez aider tout le monde.

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 doit passer des paramètres à la fonction anonyme Et l'exécuter immédiatement

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

Peu importe le moment où vous lisez le code , vous devez faire attention aux 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 qui est 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, Herophant.com

Les fonctions anonymes ont la forme :

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

J'essaie de faire comprendre à tout le monde aujourd'hui l'idée que les fonctions anonymes ne doivent généralement être utilisées que lorsqu'elles sont 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 des 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 qu'il y ait maintenant 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 !

Maintenant, nous devons le retrouver. En utilisant notre fonction soigneusement nommée, nous obtenons la trace de pile suivante :

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

Mais... une fois que nous avons corrigé cela, 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, quelle sera la sortie de la console ?

Eh bien, au moins, nous avons toujours 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 de mappage de code 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 entière assez misérable.

Lisibilité

Hé, j'ai entendu dire que tu n'y croyais 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 !

Regardez les 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 déjà ce que je vais dire. Notre méthode renvoie une promesse, et nous utilisons cet objet/méthode de promesse pour gérer différentes réponses possibles.

Vous pensez peut-être 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);

D'accord, soyons clairs : cette partie du code est plus longue, mais je pense qu'elle est plus que simplement plus lisible ! Nos fonctions soigneusement nommées sont différentes des fonctions anonymes dans le sens où nous savons quelle est leur fonction dès que nous voyons leurs noms. Cela évite les obstacles lors de l’évaluation du code.

Cela permet également de clarifier la relation. Au lieu de créer une méthode, de la transmettre, puis d'exécuter la logique, dans le deuxième exemple, les arguments sont donnés à then et catch pointe simplement vers la fonction où tout se passe.

Je ne peux rien vous dire de plus pour être plus lisible. Mais peut-être que si vous n'êtes pas encore convaincu, je peux essayer un dernier argument.

Recommandations associées :

Le problème de la définition de fonctions anonymes pour les boucles de boutons dans js

Fonctions anonymes couramment utilisées

Explication détaillée de l'utilisation de la fonction anonyme js et exemples de passage de paramètres

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!