Un développeur énonce les 12 règles à respecter
Pour écrire un code JavaScript professionnel

Le , par Victor Vincent, Chroniqueur Actualités
JavaScript est un langage de script orienté objet principalement utilisé dans les pages dynamiques et interactives mais également, et cela de plus en plus, il est utilisé côté serveur. Comme pour tout autre langage, pour écrire un code qui exploite au mieux ses capacités, il est nécessaire de respecter certaines règles et de bonnes pratiques selon Cory House, expert développeur et Microsoft MVP.

Règle n°1 : Écrire du JavaScript dans un fichier séparé

On pourrait être tenté de coder en dur ses scripts JS car ceux-ci sont généralement constitués seulement de quelques lignes de codes. Cependant le fait de les écrire dans des fichiers à part a l'avantage de permettre une meilleure lisibilité et une bonne structuration de son code. Contrairement aux scripts codés en dur, les fichiers JS sont stockés dans la mémoire cache évitant ainsi des aller-retour au serveur qui peuvent s'avérer coûteux en bande passante.

Règle n°2 : Le code Javascript doit être "statique"

Certains développeurs utilisent des langages comme C#, Ruby ou encore Java pour générer coté serveur du code JS dynamique. Cela est à éviter ne serait-ce que pour bénéficier de la coloration syntaxique dans son éditeur. Il faudrait plutôt utiliser JSON pour donner un comportement dynamique à son application sans pour autant que le code JS change en soit. Ce mécanisme est utilisé notamment par Stackoverflow comme vous pouvez le voir sur cette portion de code source dans laquelle des paramètres personnels comme isNoticesTabEnabled sont injectés. Ce faisant, JSON fournit les données nécessaires pour un rendu dynamique coté client en gardant son code "statique".



Règle n°3 : Le code Javascript doit être minimaliste

Le code JS doit être le plus minimaliste possible. Cela permet de faciliter le chargement des fichiers .js allégeant ainsi le serveur. Cela nous fait gagner en performance qui, rappelons le, est un critère de qualité d'une application. Il existe plusieurs manières de réduire la taille des fichiers .js, l'une d'entre elle est l'utilisation de task runners tels que Gulp.

Règle n°4 : Inclure le Javascript en bas de page

Le fait d'inclure la balise <script> dans le tag <head>de la page bloque le chargement de celle-ci. En effet le contenu du <head> doit obligatoirement être chargé avant que le contenu du <body> puisse être affiché. Pour éviter cela, il est donc préférable d'inclure les .js en fin de page juste après le tag </body>pour ne pas être obligé d'attendre le chargement des scripts avant de pouvoir afficher le reste de la page.

Règle n°5 : Écrire des fonctions de test automatique pour tester son code

Javascript est de plus en plus utilisé côté serveur avec beaucoup de logique métier derrière. Dès lors, vouloir tester son code JS manuellement devient presque un casse-tête. Il devient donc impératif d'automatiser les tests. Il existe une variété d'outils d'automatisation de test. Pour les tests unitaire par exemple, Jasmine est un assez bon choix quand on est débute dans le test Javascript mais pour des gens expérimentés dans le domaine, Mocha avec Chai est un meilleur choix.

Règle n°6 : Utiliser le pattern Module pour encapsuler son code Javascript

L'utilisation du pattern Module est pressenti par certains développeurs comme étant l'avenir de l'encapsulation de code JS. Même s'il n'est pas encore pris en charge par les navigateur, on peut aujourd'hui utiliser Module ES6 pour "transpiler" via Babel. Pour ceux qui n'utilisent pas ce mécanisme, CommonJS est un bon choix pour le moment.

Règle n°7 : Les dépendances Javascript doivent être explicites

Cette règle est étroitement liée à la règle précédente. Une fois que vous avez commencé à encapsuler votre code JS, vous avez besoin d'un moyen facile de faire référence à d'autres modules. C'est à ce niveau que des modules modernes comme CommonJS et ES6 nous facilitent la vie. Cela se fait simplement en spécifiant vos dépendances au début du fichier, un peu comme une importation ou une déclaration en utilisant Java ou C#.

Règle n°8 : Utiliser des framework et des bibliothèques

Il existe une panoplie de framework Javascript dans le monde du développement logiciel. Le choix est large, de Backbone à Angular en passant par Backbone ou encore Ember. Ce qu'il ne faut éviter à c'est d'essayer de partir de zéro, il faut toujours partir d'un base solide avec un de ces frameworks et selon les besoins et les préférences on pourra juger nécessaire d'en adopter un autre ou de continuer avec le premier.

Règle n°9 : Séparer la présentation de la logique métier et de l'accès aux données

A ce niveau il ne s'agit pas simplement de faire une séparation en modèle, vue, contrôleur comme c'est le cas avec les framework MVC tels qu' Angular ou encore Knockout. Il s'agit plutôt de raisonner comme un développeur côté serveur en séparant votre présentation de la logique métier ainsi que de l'accès aux données. Pour ce faire, les appels AJAX doivent tous être à un seul endroit et vous devez créer une couche d'accès aux données centralisée côté client. Cela implique également que toute logique ne faisant pas partie de la couche présentation doit résider dans des classes POJO (Plain Old Javascript Object). Les modules contenant la logique métier doit ne doit contenir que du code Javascript simple, c'est à dire qu'il ne faut pas utiliser de code spécifique à un framework à ce niveau.

Règle n°10 : S'assurer que son site continue de tourner sans Javascript

Javascript permet de rendre les sites plus agréables du points de vue de leurs contenu. Cependant il ne doit pas être indispensable à un site pour être opérationnel. Cela peut être une assez mauvaise chose pour l'accessibilité du site.

Règle n°11 : Initialiser les variables au début du script

Initialiser les variable au début du script permet :
  • de rendre le code plus lisible
  • de regrouper les déclarations de variable à un seul niveau
  • d'éviter d'avoir des variables non initialisées


Règle n°12 : Éviter l'utilisation de la fonction eval()

La fonction eval() est utilisée pour exécuter du texte comme du code mais dans presque tous les cas son utilisation n'est pas obligatoire. C'est une fonction qui permet d'exécuter du code arbitraire ce qui peut présenter un problème de sécurité dans bien des cas.

Sources : Blog, W3Schools, Github

Et vous ?

Quel est votre point de vue ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
le 26/09/2015 à 20:16
Règle 3: bien évidemment, le code JS doit être minifié en production (et ce grâce à Uglify ou Closure Compiler, les task runners comme Gulp n'étant que le moyen d'automatiser le recours à ces outils). Mais dans le code "écrit" par les développeurs, comme l'entend le titre, il ne faut pas hésiter à commenter ou à utiliser des noms de variables longs et clairs. Un code simple et lisible n'est pas forcément minimaliste.

Règle 4: Le positionnement des balises <script> est un sujet plus complexe qui n'y paraît. J'ai donné plus de détails ici : http://www.developpez.net/forums/d15...y/#post8371661 ; mettre tous les <script> dans <head> avec l'attribut defer est aujourd'hui le meilleur compromis.

Règle 5: "mocha" et non "Moka"

Règle 10: sur les sites pros que je gère, moins de 1% des requêtes entrantes n'ont pas JavaScript activé. Aussi, le fait que les lecteurs d'écran pour déficients visuels ne sachent pas éxécuter JavaScript est une idée reçue: en réalité, la majorité savent très bien le gérer: http://a11yproject.com/posts/myth-sc...se-javascript/. Le seul problème qui peut encore se poser avec la désactivation JavaScript concerne les bots d'indexation et la SEO, mais rien n'empêche de fournir une page alternative avec <noscript> et <meta> redirect vers une page explicative bourrée de mots-clés.

Règle 11: aucun sens, pourquoi en début de script ? Si on déclare toutes ses variables en début de fichier, on perd tout l'intérêt des closures et du scope lexical qui est un gros point fort de JavaScript

Du reste, d'accord avec tout ! La modularité et la testabilité notamment sont des critères très importants pour un code dit "professionnel".
Avatar de Sodium Sodium - Membre éclairé https://www.developpez.com
le 27/09/2015 à 10:40
Règle 10: sur les sites pros que je gère, moins de 1% des requêtes entrantes n'ont pas JavaScript activé. Aussi, le fait que les lecteurs d'écran pour déficients visuels ne sachent pas éxécuter JavaScript est une idée reçue: en réalité, la majorité savent très bien le gérer: http://a11yproject.com/posts/myth-sc...se-javascript/. Le seul problème qui peut encore se poser avec la désactivation JavaScript concerne les bots d'indexation et la SEO, mais rien n'empêche de fournir une page alternative avec <noscript> et <meta> redirect vers une page explicative bourrée de mots-clés.

Là n'est en fait pas tellement la question. Que le client gère JavaScript ou pas, JavaScript ne doit pas être utilisé pour construire la page mais pour y ajouter de l'interactivité. Tout le contenu d'un site doit être conçu de manière statique et tout doit pouvoir être accédé par une url. Une fois les bases établies, on peut ensuite utiliser du script pour aller récupérer des données et les injecter de manière dynamique dans la page.

Je vois de plus en plus de sites dont la mise en page part complètement en sucette sans JavaScript parce que de nombreux éléments de style sont calculés au chargement de la page, problème qui est visible lorsque que le code ne s'exécute pas avant l'affichage. Cela traduit généralement une méconnaissance du CSS, on peut dans pratiquement tous les cas résoudre une majorité de problèmes de mise en page avec les bonnes propriétés.
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
le 27/09/2015 à 13:36
Je ne faisais pas allusion aux bêtes plugins UI. JavaScript a bien évolué et son rôle ne se résume plus à une couche de peinture appliquée sur un document. Aujourd'hui, les avantages du templating et du routage côté client sont indéniables: on diminue la taille des requêtes (data on wire, voire des diffs patchs), on a une gestion du cache plus fine (applicationCache, service workers, localStorage) et des transitions de page plus fluides (single page app, navigation en arrière à coût zéro etc...). L'utilisateur y est totalement gagnant.

En ce moment, on entend beaucoup parler des applications isomorphiques ( ou universal JS, shared JS ), qui utilisent tous les avantages du JS tout en étant capable de générer leurs pages côté serveur pour les utilisateurs sans JavaScript, et aussi pour booster le temps d'affichage de la première page, première visite. Du fait de leur polyvalence, ces solutions sont pressenties pour être les meilleures et donc la "best practice". Là encore, je ne suis pas d'accord. D'abord car comme expliqué dans mon post précédent, le non-support de JS est anecdotique et ce n'est pas une fatalité, il diminue chaque année. Ensuite, le cas de la première page et première visite peut être géré de manière totalement différente: accompagnement de l'utilisateur, chargement progressif de l'interface en mode "découverte"... les marketeux adorent ça. Enfin, les mécaniques dites isomorphiques ne sont pas si simples à implémenter et compliquent les process de tests, ce qui me laisse à penser que si l'idée en soi est plutôt bonne, elle n'est pas à imposer comme "bonne pratique" à tout le monde, seulement à ceux qui se doivent de gérer ces fameux 1%.
Avatar de Sodium Sodium - Membre éclairé https://www.developpez.com
le 27/09/2015 à 14:54
Du fait de leur polyvalence, ces solutions sont pressenties pour être les meilleures et donc la "best practice". Là encore, je ne suis pas d'accord. D'abord car comme expliqué dans mon post précédent, le non-support de JS est anecdotique et ce n'est pas une fatalité

Un seul argument suffit à démonter ceci : je peux prédire à quoi mes pages ressembleront dans cinq ans tant que j'ai la main sur mon serveur. Je ne peux par contre absolument pas prédire comment les navigateurs interprêteront mon code JavaScript d'ici-là.

accompagnement de l'utilisateur, chargement progressif de l'interface en mode "découverte"... les marketeux adorent ça.

Les marketeux oui, les visiteurs non. Le visiteur moyen vient chercher une information précise sur un site. Il déteste la pub et n'a absolument pas envie de passer par un tunnel de storytelling avec call-to-action pour essayer de lui vendre un produit. Dans 95% des cas, il est venu chercher un horaire, une adresse ou un numéro de téléphone et ne peut-être qu'agressé un site web promotionnel.
Avatar de NoSmoking NoSmoking - Modérateur https://www.developpez.com
le 27/09/2015 à 17:05
Bonjour,
Citation Envoyé par SylvainPV
Règle 11: aucun sens, pourquoi en début de script ? Si on déclare toutes ses variables en début de fichier, on perd tout l'intérêt des closures et du scope lexical qui est un gros point fort de JavaScript

je pense qu'il parle plutôt du top de la fonction sinon effectivement aucun sens !
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
le 27/09/2015 à 18:26
Citation Envoyé par Sodium  Voir le message
Je ne peux par contre absolument pas prédire comment les navigateurs interprêteront mon code JavaScript d'ici-là.

On pourrait tenir le même discours avec HTML et CSS, mais il n'y a aucun risque. Personne ne va briser la sacro-sainte rétro-compatibilité de JavaScript. Le moindre changement à la façon dont un navigateur interprète le JavaScript a des conséquences dramatiques, en cassant des milliers de pages existantes. On a pu l'observer avec la gestion des événements tactiles dans Chrome desktop, ils ont tout de suite fait marche arrière en voyant les plaintes d'utilisateurs pleuvoir. D'ailleurs, mes plus anciens projets JavaScript (~2006) fonctionnent encore parfaitement sur les navigateurs actuels, si on omet les bugs dû à mon incompétence à l'époque .

@NoSmoking: avec l'opérateur let de ES6, tout mettre en début de fonction n'a plus de sens non plus.
Avatar de ABCIWEB ABCIWEB - Expert éminent https://www.developpez.com
le 27/09/2015 à 21:27
Citation Envoyé par Sodium  Voir le message
Un seul argument suffit à démonter ceci : je peux prédire à quoi mes pages ressembleront dans cinq ans tant que j'ai la main sur mon serveur. Je ne peux par contre absolument pas prédire comment les navigateurs interprêteront mon code JavaScript d'ici-là.

C'est un discours plus théorique que pratique ou qui ne vaut que pour les serveurs dédiés. Concernant les mutualisés, il y a deux types d'hébergeurs, ceux qui utilisent une version obsolète du langage serveur qu'ils maintiennent des années et des années (effectivement bien plus de cinq ans) et ceux qui utilisent les dernières versions. Dans ce cas on a accès aux dernières fonctionnalités et une meilleure sécurité (surtout par rapport à des versions qui ne sont plus maintenues) mais il faudra faire des mises à jour plus souvent.

Par contre javascript ne peut pas se permettre de déprécier des fonctions "standard" (je ne connais pas d'exemple). Et si on peut émettre l'hypothèse qu'un nouveau langage vienne un jour supplanter javascript, il faudra bien plus de cinq ans avant que les navigateurs ne l'interprète plus car ce serait se priver de l'ancien monde déjà très vaste (très dommageable pour un "navigateur").

Après il y a toujours des annonces de révolutions etc. google étant très fort à ce jeu. Ils profitent de la supériorité indéniable de leur algo de recherche pour faire croire qu'ils sont aussi en avance dans les autres domaines, ce qui n'est pas le cas. On a vu le flop de dart, et tout un tas d'autres "révolutions" avortées malgré la puissance médiatique et financière de google pour les promouvoir...
Avatar de MikeRowSoft MikeRowSoft - Provisoirement toléré https://www.developpez.com
le 27/09/2015 à 21:36
En voyant tous sa je comprend mieux pourquoi l'unité de mesure Bauds/s à disparu au profit du Kilobit/s.
En tous cas (chante):
c'est bon pour programmer!
c'est bon pour programmer!
C'est bon bon.

Manque plus qu'un gestionnaire de téléchargent supportant le MD5 durant le transfert, écrit en JavaScript bien sûr. Un de mes précédents commentaires au sujet du MD5 devrait provoquer un râle bol.
Et donc de nouvelles règles pour arrêter définitivement cette possibilité.
Avatar de mrqs2crbs mrqs2crbs - Membre averti https://www.developpez.com
le 28/09/2015 à 10:28
Citation Envoyé par Victor Vincent  Voir le message
Règle n°6 : Utiliser le pattern Module pour encapsuler son code Javascript

L'utilisation du pattern Module est pressenti par certains développeurs comme étant l'avenir de l'encapsulation de code JS. Même s'il n'est pas encore pris en charge par les navigateur, on peut aujourd'hui utiliser Module ES6 pour "transpiler" via Babel. Pour ceux qui n'utilisent pas ce mécanisme, CommonJS est un bon choix pour le moment

Je ne vois pas pourquoi il faut utiliser Babel ou CommonJS pour écrire ses namespaces...
s'il y en a parmi vous qui utilisent ces bibliothèques, je veux bien une petite explication.
Avatar de SylvainPV SylvainPV - Rédacteur/Modérateur https://www.developpez.com
le 28/09/2015 à 11:11
Pas pour de simples namespaces, c'est-à-dire ranger ses données et fonctions dans des espaces de noms accessibles globalement. Mais pour le pattern module complet, qui requiert explicitement ses dépendances et n'expose aucune globale, il faut un module loader. Et comme la spec finale des modules ES6 a été publiée, autant l'utiliser tout de suite avec un transpileur comme Babel.
Offres d'emploi IT
Ingénieur php confirmé / senior
ekino / Fullsix Group - Ile de France - Levallois-Perret (92300)
Ingénieur data sénior – plateforme web tv disruptif
Mobiskill - Ile de France - Paris (75000)
Pilote de plateformes de service
HUMANLOG - Provence Alpes Côte d'Azur - Sophia Antipolis

Voir plus d'offres Voir la carte des offres IT
Contacter le responsable de la rubrique Accueil