IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

JavaScript Discussion :

12 règles à respecter pour écrire un code JavaScript professionnel


Sujet :

JavaScript

  1. #1
    Expert éminent sénior

    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Janvier 2013
    Messages
    320
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Sénégal

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Janvier 2013
    Messages : 320
    Points : 27 370
    Points
    27 370
    Billets dans le blog
    1
    Par défaut 12 règles à respecter pour écrire un code JavaScript professionnel
    Un développeur énonce les 12 règles à respecter
    pour écrire un code JavaScript professionnel

    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".

    Nom : Capture d’écran 2015-09-26 à 13.53.37.png
Affichages : 19163
Taille : 248,6 Ko

    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 ?

  2. #2
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Points : 9 944
    Points
    9 944
    Par défaut
    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".
    One Web to rule them all

  3. #3
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    Avril 2014
    Messages
    2 324
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : Avril 2014
    Messages : 2 324
    Points : 2 006
    Points
    2 006
    Billets dans le blog
    1
    Par défaut
    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.

  4. #4
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Points : 9 944
    Points
    9 944
    Par défaut
    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%.
    One Web to rule them all

  5. #5
    Membre extrêmement actif
    Avatar de Sodium
    Femme Profil pro
    Développeuse web
    Inscrit en
    Avril 2014
    Messages
    2 324
    Détails du profil
    Informations personnelles :
    Sexe : Femme
    Localisation : Belgique

    Informations professionnelles :
    Activité : Développeuse web

    Informations forums :
    Inscription : Avril 2014
    Messages : 2 324
    Points : 2 006
    Points
    2 006
    Billets dans le blog
    1
    Par défaut
    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.

  6. #6
    Modérateur

    Avatar de NoSmoking
    Homme Profil pro
    Inscrit en
    Janvier 2011
    Messages
    16 939
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Isère (Rhône Alpes)

    Informations forums :
    Inscription : Janvier 2011
    Messages : 16 939
    Points : 44 112
    Points
    44 112
    Par défaut
    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 !

  7. #7
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Points : 9 944
    Points
    9 944
    Par défaut
    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.
    One Web to rule them all

  8. #8
    Expert éminent sénior

    Homme Profil pro
    Développeur Web
    Inscrit en
    Septembre 2010
    Messages
    5 380
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Septembre 2010
    Messages : 5 380
    Points : 10 410
    Points
    10 410
    Par défaut
    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...

  9. #9
    MikeRowSoft
    Invité(e)
    Par défaut
    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é.
    Dernière modification par MikeRowSoft ; 27/09/2015 à 22h54.

  10. #10
    Membre averti
    Avatar de mrqs2crbs
    Profil pro
    LEAD DEV
    Inscrit en
    Juin 2013
    Messages
    105
    Détails du profil
    Informations personnelles :
    Localisation : France, Rhône (Rhône Alpes)

    Informations professionnelles :
    Activité : LEAD DEV

    Informations forums :
    Inscription : Juin 2013
    Messages : 105
    Points : 398
    Points
    398
    Billets dans le blog
    2
    Par défaut
    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.

  11. #11
    Rédacteur/Modérateur

    Avatar de SylvainPV
    Profil pro
    Inscrit en
    Novembre 2012
    Messages
    3 375
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Novembre 2012
    Messages : 3 375
    Points : 9 944
    Points
    9 944
    Par défaut
    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.
    One Web to rule them all

  12. #12
    Membre à l'essai
    Profil pro
    Inscrit en
    Octobre 2005
    Messages
    9
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : Suisse

    Informations forums :
    Inscription : Octobre 2005
    Messages : 9
    Points : 11
    Points
    11
    Par défaut framework javascript
    Concernant les framework, je vous conseil de jeter un oeil à Meteor.js : http://www.meteor.com. Vous risquez adorer!

  13. #13
    Membre du Club
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    35
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 35
    Points : 67
    Points
    67
    Par défaut
    C'est un peu de l'enfonçage de porte ouverte...

  14. #14
    Expert éminent sénior
    Avatar de Marco46
    Homme Profil pro
    Développeur informatique
    Inscrit en
    Août 2005
    Messages
    4 413
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Août 2005
    Messages : 4 413
    Points : 19 608
    Points
    19 608
    Par défaut
    Citation Envoyé par Sodium Voir le message
    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.
    Donc si on résume tu penses que l'architecture REST et les webapp sont un mauvais choix par rapport à une génération complète côté serveur ?
    Un problème avec Git ? Essayez la FAQ, sinon posez votre question sur le forum.



    "Toute personne croyant qu'une croissance exponentielle peut durer indéfiniment dans un monde fini est soit un fou, soit un économiste."
    Kenneth E. Boulding

    "Les richesses naturelles sont inépuisables, car, sans cela, nous ne les obtiendrions pas gratuitement. Ne pouvant être ni multipliées ni épuisées, elles ne sont pas l’objet des sciences économiques."
    Jean-Baptiste Say, Traité d'économie politique, 1803.

    "/home/earth is 102% full ... please delete anyone you can."
    Inconnu

  15. #15
    Membre régulier
    Homme Profil pro
    Développeur Web
    Inscrit en
    Janvier 2016
    Messages
    35
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Congo-Kinshasa

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Matériel informatique

    Informations forums :
    Inscription : Janvier 2016
    Messages : 35
    Points : 114
    Points
    114
    Par défaut
    Ce sont pour la plupart des règles qu'on voit ça et là. Mais ils sont parfois discutables.

    Je prends le point 8: utilisation obligatoire de frameworks et librairies. D'aucun pensent qu'utiliser les librairies (jQuery et autres p.exemple) n'est plus vraiment utile aujourd'hui alors que le DOM est standardisé. En plus ça cache la logique du JS pure aux débutants.

    Sinon c'est bon en général

  16. #16
    Expert confirmé
    Avatar de Doksuri
    Profil pro
    Développeur Web
    Inscrit en
    Juin 2006
    Messages
    2 450
    Détails du profil
    Informations personnelles :
    Âge : 54
    Localisation : France

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Juin 2006
    Messages : 2 450
    Points : 4 600
    Points
    4 600
    Par défaut
    petite coquille (double Backbone)
    de Backbone à Angular en passant par Backbone ou encore Ember
    Sinon, c'est toujours bien de rapeller les bonnes pratiques
    La forme des pyramides prouve que l'Homme a toujours tendance a en faire de moins en moins.

    Venez discuter sur le Chat de Développez !

  17. #17
    Membre confirmé Avatar de Aizen64
    Profil pro
    Inscrit en
    Mai 2007
    Messages
    561
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2007
    Messages : 561
    Points : 462
    Points
    462
    Par défaut
    Règle n°1 : Écrire du JavaScript dans un fichier séparé
    100 fois plus facile à maintenir de cette manière. Sur mes méthodes PHP appelés via des appels JS, je fais référence au script appelant sur un commentaire PHPDoc @used-by "reference du fichier JS". Idem pour des templates qui sont renvoyés suite à un appel AJAX, je fais référence en en-tête du template à la méthode qui appelle celui ci ainsi qu'au fichier JS qui génère l'appel. Verbeux mais utile.

    Règle n°2 : Le code Javascript doit être "statique"
    Je bosse justement sur un projet qui mixe allègrement du PHP et JS, une horreur. A ne jamais faire ! C'est juste très très chiant à débugger.

    Règle n°3 : Le code Javascript doit être minimaliste
    Pour virer les espaces ? Tout dépend du cas de figure. L'utilise uniquement jQuery actuellement et, oui, l'utilise la version sans espace. Pour tous mes autres fichiers JS qui génères des appels AJAX, je ne les minifient pas, la quantité de code n'est pas énorme et les espaces non plus. En revanche, je versionne les fichiers en les suffixant du numéro de version de l'App en production. Cela permet aux utilisateurs de ne pas avoir de vieux bugs JS à cause d'erreurs que j'ai faites précédement puis corrigés qu'ils pourraient encore avoir à cause du cache du navigateur.

    Règle n°8 : Utiliser des framework et des bibliothèques
    Oui et non, pour l'AJAX, jQuery aide bien et se débrouille aussi pour des updates du DOM. Les autres frameworks, tout dépend du besoin, j'ai encore bien du mal à cerner la plus-value d'Angular sur jQuery sur mes besoin actuels. Trouver un bon compromis entre besoins fonctionnels et complexité du framework me semble important.
    Exprimer une différence d'opinion vaut mieux que :

  18. #18
    Membre confirmé
    Homme Profil pro
    Analyse système
    Inscrit en
    Mai 2014
    Messages
    388
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : Arménie

    Informations professionnelles :
    Activité : Analyse système
    Secteur : Arts - Culture

    Informations forums :
    Inscription : Mai 2014
    Messages : 388
    Points : 578
    Points
    578
    Par défaut
    Bonsoir,

    Règle n°4 : ... il est donc préférable d'inclure les .js en fin de page juste après le tag </body>...
    Avec Mozilla Firefox, si je respecte cette règle et que je fais un CTRL+U pour afficher le code, du rouge apparaît montrant une erreur de syntaxe.

  19. #19
    Expert éminent sénior

    Homme Profil pro
    Développeur Web
    Inscrit en
    Septembre 2010
    Messages
    5 380
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Puy de Dôme (Auvergne)

    Informations professionnelles :
    Activité : Développeur Web
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Septembre 2010
    Messages : 5 380
    Points : 10 410
    Points
    10 410
    Par défaut
    Oui mais c'est une erreur sans importance. Pour éviter cette "erreur" si tu y tiens, tu peux mettre le code javascript à la fin du code html juste avant le tag </body>

  20. #20
    Futur Membre du Club
    Homme Profil pro
    Étudiant
    Inscrit en
    Novembre 2016
    Messages
    19
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Étudiant
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Novembre 2016
    Messages : 19
    Points : 5
    Points
    5
    Par défaut
    Règle d'or pour le chroniqueur : Ne pas faire de fautes d'orthographe dans les titres de ses posts ("Javacript")!!!!!

Discussions similaires

  1. Réponses: 1
    Dernier message: 01/10/2016, 22h02
  2. COWL: une API DOM pour éviter aux codes JavaScript de voler des données
    Par Amine Horseman dans le forum Général JavaScript
    Réponses: 3
    Dernier message: 08/10/2014, 16h28
  3. Réponses: 3
    Dernier message: 14/05/2009, 18h15
  4. Réponses: 6
    Dernier message: 15/01/2008, 19h51
  5. Réponses: 1
    Dernier message: 17/04/2007, 14h07

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo