53 votes

Quels anti-modèles existent pour JavaScript?

Je trouve que ce que ne pas le faire est une tâche plus difficile leçon à apprendre que ce qui doit être fait.

De mon expérience, de ce qui sépare un expert d'un intermédiaire est la possibilité de choisir parmi diverses apparemment équivalent façons de faire la même chose.

Donc, quand il s'agit de JavaScript, ce genre de choses, il ne faut pas faire et pourquoi?

Je suis en mesure de trouver beaucoup de ces pour Java, mais depuis JavaScript typique du contexte (dans un navigateur) est très différent de Java, je suis curieux de voir ce qui vient.

48voto

annakata Points 42676

Langue:

  • Espace de noms polluantes par la création d'une grande empreinte de variables dans le contexte mondial.

  • La liaison de gestionnaires d'événements dans la forme 'foo.onclick = mafonction' (inextensible, devrait être à l'aide de attachEvent/addEventListener).

  • L'utilisation d'eval dans presque n'importe quel non-JSON contexte

  • Presque chaque utilisation du document.écrire (utiliser les méthodes du DOM comme document.createElement)

  • Prototypage à l'encontre de l'Objet de l'objet (BOOM!)

  • Une petite de ce, mais de faire un grand nombre de chaîne concats avec un '+' (création d'un tableau et de se joindre à elle est beaucoup plus efficace)

  • Se référant à la non-existants undefined constante

Conception/Déploiement:

  • (De manière générale) ne fournissant pas de noscript soutien.

  • Pas l'emballage de votre code en une seule ressource

  • Mettre en ligne (c'est à dire corps) des scripts près de la partie supérieure du corps (ils bloquent le chargement)

Ajax spécifiques:

  • en n'indiquant pas le début, la fin ou l'erreur d'une demande de l'utilisateur

  • d'interrogation

  • en passant et l'analyse de XML au lieu de JSON ou en HTML (le cas échéant)

edit: je continue à penser de plus!

20voto

Triptych Points 70247

En plus de ceux déjà mentionnés...

  • À l'aide de l' for..in construire pour itérer sur tous les tableaux
    (itère sur les méthodes de tableau ET indices)

  • À l'aide de Javascript inline comme <body onload="doThis();">
    (rigides et empêche plusieurs écouteurs d'événement)

  • À l'aide de la "Fonction ()" constructor
    (mauvais pour les mêmes raisons, eval() c'est mauvais)

  • Le passage des chaînes plutôt que les fonctions d' setTimeout ou setInterval
    (utilise également eval() en interne)

  • En s'appuyant sur l'implicite des énoncés par la non-utilisation des points-virgules
    (mauvaise habitude de ramasser, et peut entraîner un comportement inattendu)

  • À l'aide de /* .. */ pour bloquer les lignes de code
    (peut interférer avec la regex littéraux, par exemple: /* /.*/ */)

    <évangélisation> Et bien sûr, pas à l'aide de Prototype ;) </évangélisation>

12voto

Rakesh Pai Points 9905

Le plus important pour moi n'est pas de comprendre le JavaScript langage de programmation lui-même.

  • La surutilisation de l'objet de hiérarchies et de la construction de très profond héritage des chaînes. Peu profonde hiérarchies de bien fonctionner dans la plupart des cas en JS.
  • Ne pas comprendre prototype de l'orientation de l'objet, et, au lieu de la construction d'énormes quantités d'échafaudage pour faire de JS se comportent comme les langages à objets.
  • Inutilement à l'aide OO paradigmes lors de la procédure ou de la programmation fonctionnelle pourrait être plus concis et efficace.

Puis il y a ceux pour l'exécution navigateur:

  • Pas à l'aide de bonnes établi les motifs d'événement comme la manifestation de la délégation ou de l'observateur modèle (pub/sub) pour optimiser la gestion des événements.
  • Fréquentes DOM mises à jour (comme .appendChild dans une boucle), lorsque les nœuds DOM, peut-être dans la mémoire et ajouté en une seule fois. (ÉNORME avantage en termes de performances).
  • La surutilisation de bibliothèques pour la sélection des nœuds complexes de sélecteurs lorsque natif méthodes peuvent être utilisées (getElementById, getElementByTagName, etc.). Cela devient de moins d'un problème de nos jours, mais il vaut la peine de mentionner.
  • L'extension DOM objets lorsque vous vous attendez à des scripts tiers pour être sur la même page que la vôtre (vous allez vous retrouver casser les uns les autres du code).

Et enfin les problèmes de déploiement.

  • Pas minifying vos fichiers.
  • Web-serveur configs - pas gzipping vos fichiers en cache pas leur confidentialité.

<fiche> j'ai un peu de côté client conseils d'optimisation qui couvrent certaines des choses que j'ai mentionné ci-dessus, et de plus, sur mon blog.</plug>

9voto

Jason S Points 58434
  • détection du navigateur (au lieu de vérifier si les méthodes / champs spécifiques que vous voulez utiliser existent)
  • en utilisant alert () dans la plupart des cas

Voir aussi "Javascript: les bonnes parties" de Crockford pour d'autres choses à éviter. ( edit: attention, il est un peu strict dans certaines de ses suggestions, comme l'utilisation de "===" au lieu de "==", prenez-les donc avec le grain de sel qui vous convient le mieux)

8voto

Vilx- Points 37939

Quelques petites choses sur ma tête. Je vais éditer cette liste quand je pense à plus.

  • Ne polluez pas l'espace de noms global. Organiser les choses dans des objets à la place;
  • Ne pas omettre 'var' pour les variables. Cela pollue l'espace de noms global et pourrait vous causer des problèmes avec d'autres scripts similaires.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X