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 :

Bonnes pratiques JavaScript [Débat]


Sujet :

JavaScript

  1. #81
    Expert confirmé
    Avatar de le_chomeur
    Profil pro
    Développeur informatique
    Inscrit en
    Février 2006
    Messages
    3 653
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Février 2006
    Messages : 3 653
    Points : 4 835
    Points
    4 835
    Par défaut
    Pour clore , il ne s'agit pas d'une bonne pratique javascript mais d'une bonne pratique de code tout cours , comme les include , les content etc ( dans divers langages. )
    est ton ami fait gagner du temps à ceux qui aident , donc un message avec la balise résolu laisse plus de temps pour résoudre d'autres problèmes

    Premier ministre du CCMPTP (Comité Contre le Mot "Problème" dans les Titres de Posts )

  2. #82
    Membre régulier Avatar de Lideln75
    Profil pro
    Inscrit en
    Novembre 2008
    Messages
    111
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Novembre 2008
    Messages : 111
    Points : 102
    Points
    102
    Par défaut
    Bonsoir à tous !

    En voyant ce merveilleux topic, je ne peux pas m'empêcher de vous donner une liste des pratiques que j'utilise dans mes développements. Ca n'en fait pas une vérité absolue, mais simplement je les trouve pratiques et sécurisées.

    Certaines choses peuvent (très probablement) avoir déjà été dites, mais je fais juste un récapitulatif de ce qui me concerne, en espérant que ça pourra apporter une petite pierre à l'édifice de ce (brillant) topic !

    Utiliser un Framework
    Pourquoi ? Pour ne pas réinventer la roue. Pour ne pas se prendre la tête avec les compatibilités de navigateurs (genre votre problème de innerHTML, par exemple). Pour passer son temps à travailler sur le coeur du problème et non des choses déjà existantes. Pour la rapidité et la sécurité : on peut penser que le code d'un framework sera plus optimisé et sécurisé que le nôtre. Etc.
    Et puis sérieusement, le code est TELLEMENT plus lisible grâce à un framework ! C'est horrible de lire du code "fait main" après ça (je vous invite à parcourir des exemples en jQuery pour vous faire une idée...).
    Personnellement j'utilise jQuery qui est très rapide, efficace, bref impeccable. A mon sens, jQuery est le Firefox des frameworks.
    En plus google propose un lien vers le jQuery minimized à jour, pratique pour le cache des navigateurs !

    Bonnes pratiques
    • Utiliser le mot-clef var ! Il n'est pas là pour rien... Et si possible initialiser ses variables aussi.
    • Tolérance zéro sur les globales : utiliser pour ça un objet statique, c'est plus propre et plus sécurisé (et quand je dis globales, je ne parle pas que des variables : les fonctions aussi !)
    • Faire attention à ne pas laisser traîner une virgule de trop à la fin d'une déclaration d'objet (bug sous IE)
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
      5
       
      var oMyObject = {
           field1: toto,
           field2: tata, // Pas bien ! Ca marche partout sauf IE
      };
    • Utiliser la notation hongroise pour déclarer ses variables, c'est plus propre et on sait tout de suite quel type de donnée on attend. (et concernant les variables, je sais pas pourquoi mais je me ferai jamais aux codes contenant des variables en français... ptet une question d'habitude)
    • Bien commenter son code et l'aérer, ça mange pas de pain, et on s'y retrouve mieux (sauts de ligne, indentation, ";", etc). Pour revenir sur un code 2 semaines après, c'est tout de suite plus agréable.
    • Minimifier (??) son code pour la production (il existe des scripts qui le font pour vous)
    • Placer son JS en fin de page.
    • Ne pas utiliser des ID de balises avec des tirets ("-") ça cause des problèmes pour jsais plus trop quoi (désolé j'ai oublié).
    • Utiliser un "_" dans ses ID pour les séparer d'un numéro, exemple :
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
       
      <div id="listItem_5238" class="listItem">blablabla</div>
      <div id="listItem_5239" class="listItem">blablabla</div>
      <div id="listItem_5240" class="listItem">blablabla</div>
       
      <script type="text/javascript">
      $('.listItem').click(function(e)
      {
         var iId = $(this).attr('id').split('_')[1];
         console.log('clic sur l\'item : ', iId);
      });
      </script>
    • De la même manière qu'on ne met pas de style inline, ne pas mettre de javascript dans les balises HTML, mais à la fin du document (comme dans l'exemple ci-dessus).
    • Utiliser des apostrophe pour les chaînes, et non des guillemets, qui sont (à mon sens, bien entendu ! ) réservés aux balises HTML.
    • Bien sûr, penser à factoriser son code...
    • Retourner du XML dans les requêtes AJAX, et non du HTML tout fait (oui je sais, c'est pourtant tentant mais jQuery facilite tellement la vie pour le parse du XML, et puis c'est tellement plus propre une réponse en XML pur... )
    • Ah et j'allais oublier : pas de code JS dans un fichier PHP/HTML : séparer dans un JS ! Et si on a besoin d'initialiser des variables grâce à PHP, alors faire :
      Code : Sélectionner tout - Visualiser dans une fenêtre à part
      1
      2
       
      SDefines.sUrlAjax = '<?php echo URL_AJAX; ?>';


    Bon voilà globalement j'ai fait le tour je pense.

    Perso je n'utilise pas trop les objets (à part les objets statiques) car pour l'instant je n'en ai pas trop l'utilité, les objets statiques me suffisent amplement.

    Par contre je ne sais plus qui disait ça, mais quelqu'un conseillait de fuir comme la peste le "eval()"... Mais à ce moment-là comment faire pour appeler une fonction d'une classe (statique) dont on construit dynamiquement le nom ?
    Du genre :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    function displayWindow(sWindowName)
    {
        eval('Window' + sWindowName + '.onInit();');
    }
    Bonne fin de soirée !

    Lideln

  3. #83
    Expert éminent sénior
    Avatar de Auteur
    Profil pro
    Inscrit en
    Avril 2004
    Messages
    7 646
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Avril 2004
    Messages : 7 646
    Points : 11 135
    Points
    11 135
    Par défaut
    Citation Envoyé par Lideln75 Voir le message

    Par contre je ne sais plus qui disait ça, mais quelqu'un conseillait de fuir comme la peste le "eval()"... Mais à ce moment-là comment faire pour appeler une fonction d'une classe (statique) dont on construit dynamiquement le nom ?
    Du genre :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
     
    function displayWindow(sWindowName)
    {
        eval('Window' + sWindowName + '.onInit();');
    }
    utilise l'objet Function()
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
     
    function displayWindow(sWindowName)
    {
        var code = "Window" + sWindowName + ".onInit();"
        var fct = new Function("", code);
        fct(); 
    }

  4. #84
    Membre actif Avatar de nod__
    Profil pro
    Étudiant
    Inscrit en
    Avril 2009
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Avril 2009
    Messages : 176
    Points : 226
    Points
    226
    Par défaut
    Oui enfin le constructeur Function et eval sont aussi mauvais l'un que l'autre… puisque Function appelle eval()…

    la vraie soluce est :
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    function displayWindow(sWindowName)
    {
        window["Window" + sWindowName].onInit();
    }
    Vu que bon, "Windowmachin" est un objet global, donc un membre du contexte d'execution "window". Douglas Crockford : Function constructor (lire la sous partie en question)

    Ah oui, pour la notation hongroise, préfixer par le type est inutile ou presque un très bon article qui explique le malentendu de cette notation Joel on software

  5. #85
    Membre régulier Avatar de Lideln75
    Profil pro
    Inscrit en
    Novembre 2008
    Messages
    111
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Novembre 2008
    Messages : 111
    Points : 102
    Points
    102
    Par défaut
    function displayWindow(sWindowName)
    {
    window["Window" + sWindowName].onInit();
    }
    Quand tu utilises "window", je pense qu'il s'agit d'un tableau global que tu auras déclaré au préalable ? (quand j'utilise "WindowMachin", c'est un objet statique x ou y hein)

    Si oui, en effet c'est la seule solution pour éviter d'utiliser eval(), mais bon franchement je trouve pas ça tip top, enfin c'est bien, mais je trouve eval() plus simple et plus parlant...

    Concernant la notation hongroise, désolé mais là par contre je ne plierai jamais. Pour avoir bossé chez des clients et récupéré du code qui n'utilisait pas cette notation, je t'assure que préfixer ses variables c'est un gain de temps monstrueux, et c'est aussi beaucoup plus agréable (et l'article donné par node__ en lien ne me convainc pas, je l'avais déjà lu avant d'ailleurs).

    Enfin encore une fois, les "règles" que j'ai citées ne sont pas parole d'Evangile, mais simplement des règles que je mets en place dans mes développements car je les trouve pratiques, sécuritaires, et agréables

  6. #86
    Membre actif Avatar de nod__
    Profil pro
    Étudiant
    Inscrit en
    Avril 2009
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Avril 2009
    Messages : 176
    Points : 226
    Points
    226
    Par défaut
    window c'est l'objet global dans lequel tout ton code JS s'execute. Tu n'as pas besoin de le déclarer il est présent dans tous les navigateurs (quand t'as du JS coté serveur forcément c'est pas pareil).
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    function truc () {}
     
    // faire 
    truc();
    // ou
    window.truc();
    C'est exactement pareil. Donc bon bah autant l'utiliser.

    Vouloir utiliser JS comme ça c'est un problème de conception. Si tu avais par exemple
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
     var Window = {
        "methode1" : function () {},
        "methode2" : function () {},
        "methode3" : function () {}
    };
     
    function displayWindow(sWindowName) {
        Window[sWindowName].onInit();
    }
    Tout simplement. appeler un objet "Window" c'est au mieux déroutant, vu que le contexte s'appele déjà "window"

    Et eval tu ne va trouver aucun dev web qui te conseil de l'utiliser, plutôt l'inverse, toi qui parle de problèmes de sécurité, c'en est un. (envoie "hep = ''; alert('owned'); methode", même combat avec Function)

    Pour la notation hongroise, je dis juste que savoir que c'est une chaine, un objet ou autre c'est moins instructif que de savoir si la variable contient une largeur de bordure (par ex. "bwTruc") ou autre, après c'est une convention comme tu dis.

  7. #87
    Membre régulier Avatar de Lideln75
    Profil pro
    Inscrit en
    Novembre 2008
    Messages
    111
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Novembre 2008
    Messages : 111
    Points : 102
    Points
    102
    Par défaut
    Ok merci pour l'info concernant l'objet "window", m'étant auto-formé (comme beaucoup) au JS, je ne suis pas forcément tombé sur des codes l'utilisant.

    Je vais ptet modifier mon code avec ton idée, donc.

    (et pour la notation hongroise, je comprends pas le rapport avec la bordure, pour une string ou un int... ?)

    A+

  8. #88
    Membre actif Avatar de nod__
    Profil pro
    Étudiant
    Inscrit en
    Avril 2009
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Avril 2009
    Messages : 176
    Points : 226
    Points
    226
    Par défaut
    dans l'article en lien avec la notation hongroise, il explique que le mot type dans la phrase du créateur de la notation a été mal interprété, il aurait fallut marquer kind puisqu'il ne parlait pas du type (int, string, etc.) mais bien du "rôle" ou du "genre" de la variable, ie. ce qu'elle fait dans le programme, les exemples qu'il donne sont explicite (et le trivia à propos d'excel est amusant).

    Sinon oui peu de codes utilisent window. Ils utilisent plutôt l'approche que j'ai présenté au dessus. D'ailleus il y a un article sur les namespaces en JS sur developpez, ça t'aidera surement a mieux apréhender le problème

  9. #89
    Membre émérite Avatar de franculo_caoulene
    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    2 880
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 2 880
    Points : 2 953
    Points
    2 953
    Par défaut
    C'est un débat, débattons :
    Citation Envoyé par Lideln75 Voir le message
    • Utiliser la notation hongroise pour déclarer ses variables, c'est plus propre et on sait tout de suite quel type de donnée on attend. (et concernant les variables, je sais pas pourquoi mais je me ferai jamais aux codes contenant des variables en français... ptet une question d'habitude)
    Je suis clairement d'accord, avec nod__ une variable ayant un nom explicite est amplement suffisant et beaucoup plus lisible.
    Citation Envoyé par Lideln75 Voir le message
    • Bien commenter son code et l'aérer, ça mange pas de pain, et on s'y retrouve mieux (sauts de ligne, indentation, ";", etc). Pour revenir sur un code 2 semaines après, c'est tout de suite plus agréable.
    Que veut dire "bien commenter un code"? C'est toute une question.
    Citation Envoyé par Lideln75 Voir le message
    • Minimifier (??) son code pour la production (il existe des scripts qui le font pour vous)
    On peut aussi parler de le compresser quand on peut le faire.
    Citation Envoyé par Lideln75 Voir le message
    • Ne pas utiliser des ID de balises avec des tirets ("-") ça cause des problèmes pour jsais plus trop quoi (désolé j'ai oublié).
    • Utiliser un "_" dans ses ID pour les séparer d'un numéro, exemple :
    Je demande plus d'explications.
    Citation Envoyé par Lideln75 Voir le message
    • Utiliser des apostrophe pour les chaînes, et non des guillemets, qui sont (à mon sens, bien entendu ! ) réservés aux balises HTML.
    Là aussi, je demande plus d'explications. Je n'ai jamais compris ce penchant pour les simples quotes, plutôt que les doubles. Je pense avoir plus de chance de manipuler des chaînes et donc de rencontrer des apostrophes que des balises (X)HTML. Je pense que c'est une déformation qui viens du PHP.
    Citation Envoyé par Lideln75 Voir le message
    • Retourner du XML dans les requêtes AJAX, et non du HTML tout fait (oui je sais, c'est pourtant tentant mais jQuery facilite tellement la vie pour le parse du XML, et puis c'est tellement plus propre une réponse en XML pur... )
    Sans oublier JSON
    Les Cours et tutoriels JavaScript
    Penser à la recherche et au bouton

  10. #90
    Expert confirmé
    Avatar de le_chomeur
    Profil pro
    Développeur informatique
    Inscrit en
    Février 2006
    Messages
    3 653
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations professionnelles :
    Activité : Développeur informatique

    Informations forums :
    Inscription : Février 2006
    Messages : 3 653
    Points : 4 835
    Points
    4 835
    Par défaut
    . . .

    J'ai longuement hésité avant de répondre aux derniers post car je trouve que l'on dévie , il n'y a plus de débat mais une projection d'idée propre a chacun via ses petites habitudes , je me trompe ???

    Pour essayer de re-cadrer un peu, sans vouloir détenir la vérité absolue, mais une pratique courante que l'on peut retrouver dans de NOMBREUX langage de programmation ( php, c# , java ... ) je vais donner MON point de vue et expliquer le pourquoi du comment ( puisqu'un débat est basé sur un point de vue ).

    Commençons par le commencement :

    Les variables

    - Utiliser des lettres minuscules et majuscules et des chiffres (abcABC012...)
    - Votre nom de variable doit commencer par une lettre, de préférence en minuscule.
    - Les espaces sont interdits , utilisez le caractère "underscore" _ à la place.
    - Utilisez la notation "Camel Case" qui consiste a utiliser une majuscule comme séparateur de mot ( exemple : faireAction ), le principe de camel case s'applique aux variables mais également aux méthode.

    pour faire un apparté sur la notation hongroise :

    "La Notation Hongroise est une convention qui vise à “pseudo-typer” les variables, en indiquant leur type dans leur nom. Par exemple, le “tableau de résultats” sera nommé aResults (pour array), le “nombre de pages” sera “nPages”…"
    La ou le bas blesse, c'est que chacun y va de sa sauce ... certain utiliseront par exemple en préfixe intNPages, la ou d'autre utiliseront nbPages ou autres ...

    Je pense qu'il est préférable de ne PAS surcharger le nom des variables, mais de les rendre explicites...

    Les commentaires

    Quand ?
    Comment ?
    Pourquoi ?

    - Quand commenter son code ?

    Il est conseillé de commenter son code tout d'abord sur CHAQUE méthode !
    Le strict minimum est de spécifié , l'appel a la méthode, les variables a passé a cette méthode et en option le TYPE de variables exemple :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    function toto(a,b){
    ...
     
    return x
    }
    pas très explicite ??

    Comment ?


    /**
    * @call : toto(a, b, c);
    * @param : int a ;
    * @param : int b ;
    * @param : int c (Optionnal);
    * @return : int x
    * Ici description succincte de la méthodes
    **/

    Voila , en 6 lignes, on vient de détailler l'appel et l'utilisation et la description d'une méthode !

    On peut ensuite commenter certaines lignes un peu plus complexes, mais il vaut mieux une bonne description de la méthode que de commenter toutes les 3 lignes...

    Pourquoi ?

    Tout simplement pour une maintenance du code !
    Que ce code soit interne a un projet, ou amener a être distribuer, il sera toujours appréciable et pratique de retrouver un code ( même mal codé ) commenter , qu'un code de niveau "expert" qu'il nous faudra des heures à comprendre.

    J'en reste la pour les principes de base, mais je pense intervenir par la suite sur d'autre points ( méthode,closure etc ... )
    est ton ami fait gagner du temps à ceux qui aident , donc un message avec la balise résolu laisse plus de temps pour résoudre d'autres problèmes

    Premier ministre du CCMPTP (Comité Contre le Mot "Problème" dans les Titres de Posts )

  11. #91
    Membre régulier Avatar de Lideln75
    Profil pro
    Inscrit en
    Novembre 2008
    Messages
    111
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Novembre 2008
    Messages : 111
    Points : 102
    Points
    102
    Par défaut
    Citation Envoyé par franculo_caoulene Voir le message
    C'est un débat, débattons : Je suis clairement d'accord, avec nod__ une variable ayant un nom explicite est amplement suffisant et beaucoup plus lisible.
    Peut-être... Mais je trouve mieux d'utiliser le préfixe donnant le type de variable (tant qu'on est dans un contexte de langage non fortement typé).
    Tiens, par exemple cette variable "modeSearchSelected", c'est quoi à ton avis ? Un objet ? Une string ? Un entier ? Impossible de le savoir. Tandis que si tu lis "iModeSearchSelected", tu sais qu'il s'agit d'un entier.
    Après chacun son truc, je veux rien imposer ici, juste proposer des idées.

    Que veut dire "bien commenter un code"? C'est toute une question.
    A mon sens, il s'agit de commenter l'en-tête des fonctions, les arguments, la valeur de retour, ainsi que les blocs de code à l'intérieur d'une fonction pour garder une explication de ce qu'on fait et surtout pourquoi on le fait.

    On peut aussi parler de le compresser quand on peut le faire.
    Oui mais c'est peu recommandé et de toutes façons il suffit d'activer la compression au niveau d'apache. Supprimer les commentaires ou autre, c'est déjà un gros gain. Obfusquer... Bof bof... Je pense que tu auras le même poids entre un JS minimifié et zippé, et un JS obfusqué (et zippé éventuellement, mais yaura plus rien à zipper).

    Je demande plus d'explications.
    J'ai donné un exemple en plus... Merci de relire

    Là aussi, je demande plus d'explications. Je n'ai jamais compris ce penchant pour les simples quotes, plutôt que les doubles. Je pense avoir plus de chance de manipuler des chaînes et donc de rencontrer des apostrophes que des balises (X)HTML. Je pense que c'est une déformation qui viens du PHP.
    En PHP tu peux très bien utiliser les double quote aussi hein... Mais encore une fois je n'impose rien ! Je trouve juste ça plus pratique lorsque tu veux insérer du code HTML depuis ton JS.

    Sans oublier JSON
    Oui oui...

    La chasse aux sorcières est finie ?
    Le but de ce topic n'est pas de casser les idées des autres (sauf si elles sont vraiment dangereuses), mais de proposer des idées de "bonne programmation".

    Enfin bon, je suis ravi d'avoir pu répondre à tes... Interrogations

  12. #92
    Membre émérite Avatar de franculo_caoulene
    Profil pro
    Inscrit en
    Octobre 2003
    Messages
    2 880
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Octobre 2003
    Messages : 2 880
    Points : 2 953
    Points
    2 953
    Par défaut
    Citation Envoyé par Lideln75 Voir le message
    La chasse aux sorcières est finie ?
    Le but de ce topic n'est pas de casser les idées des autres (sauf si elles sont vraiment dangereuses), mais de proposer des idées de "bonne programmation".
    Ceci est un débat, tu exposes ton avis et ensuite nous en débattons tous ensemble. Il n'y a rien de personnel.
    Citation Envoyé par Lideln75 Voir le message
    Tiens, par exemple cette variable "modeSearchSelected", c'est quoi à ton avis ? Un objet ? Une string ? Un entier ? Impossible de le savoir. Tandis que si tu lis "iModeSearchSelected", tu sais qu'il s'agit d'un entier.
    C'est un bon exemple de variable qui n'a pas de sens. Avec ou sans "i", je ne sais pas ce qu'elle fait.
    Citation Envoyé par Lideln75 Voir le message
    Oui mais c'est peu recommandé et de toutes façons il suffit d'activer la compression au niveau d'apache. Supprimer les commentaires ou autre, c'est déjà un gros gain. Obfusquer... Bof bof... Je pense que tu auras le même poids entre un JS minimifié et zippé, et un JS obfusqué (et zippé éventuellement, mais yaura plus rien à zipper).
    Je n'ai pas parlé de cacher le code mais de le compresser. En général, il est conseillé de compresser tout ce qui ressemble à un fichier texte. Enfin si je comprends bien les recommandations de yahoo et google. La bonne pratique est donc de minifier et compresser le code javascript.
    Citation Envoyé par Lideln75 Voir le message
    J'ai donné un exemple en plus... Merci de relire
    Je ne vois pas en quoi ton exemple montre qu'il vaut mieux utiliser l'underscore plutôt que le trait d'union. Par contre, il montre bien qu'il vaut mieux utiliser les guillemets plutôt que l'apostrophe.

    Citation Envoyé par Lideln75 Voir le message
    En PHP tu peux très bien utiliser les double quote aussi hein... Mais encore une fois je n'impose rien ! Je trouve juste ça plus pratique lorsque tu veux insérer du code HTML depuis ton JS.
    En PHP utiliser constamment les guillemets est une mauvaise pratique car plus lent (enfin si je ne me trompe pas, je ne suis pas développeur PHP). Je ne considère pas le fait d'insérer du code HTML comme une bonne pratique justement, mais plutôt l'utilisation du DOM.
    Les Cours et tutoriels JavaScript
    Penser à la recherche et au bouton

  13. #93
    Expert confirmé
    Avatar de emmanuel.remy
    Inscrit en
    Novembre 2005
    Messages
    2 855
    Détails du profil
    Informations personnelles :
    Âge : 55

    Informations forums :
    Inscription : Novembre 2005
    Messages : 2 855
    Points : 4 045
    Points
    4 045
    Par défaut
    Citation Envoyé par le_chomeur Voir le message
    . . .
    Les commentaires

    (...)
    Comment ?


    /**
    * @call : toto(a, b, c);
    * @param : int a ;
    * @param : int b ;
    * @param : int c (Optionnal);
    * @return : int x
    * Ici description succincte de la méthodes
    **/

    Voila , en 6 lignes, on vient de détailler l'appel et l'utilisation et la description d'une méthode !

    On peut ensuite commenter certaines lignes un peu plus complexes, mais il vaut mieux une bonne description de la méthode que de commenter toutes les 3 lignes...

    Pourquoi ?

    Tout simplement pour une maintenance du code !
    Que ce code soit interne a un projet, ou amener a être distribuer, il sera toujours appréciable et pratique de retrouver un code ( même mal codé ) commenter , qu'un code de niveau "expert" qu'il nous faudra des heures à comprendre.
    (...)
    J'ajouterai qu'une autre bonne raison de commenter son code c'est de pouvoir utiliser un outil qui génère la documentation du code et permet de livrer quelques chose de plus pro et évite de parcourir des tonnes de lignes ou/et de fichiers pour retrouver une fonction (Javadoc like, mais en mieux). Mais dans ce cas les annotations sont dédiées et doivent répondre à une syntaxe. Personnellement j'utilise JSDoc qui est vraiment très bien, et permet d'appliquer un template pour la génération ce qui rend l'ensemble bien plus sympa.

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    15
    16
    17
    18
     
    /**
     * Fonction qui effectue le login d'un utilisateur
     * @example
     * var loginOK = login("martin","martin 2009");
     * if (loginOK) { ... } 
     * @param{String} nom le login de l'utilisateur
     * @param {String} password son mot de pass
     * @param {String} [method="REST"] la méthode d'authentification: optionnelle et REST par défaut.
     * @returns {Boolean} Informe de la réussite du login
     */
     function logIn(nom, password, method) {
      /**
       * @function
       */
       var callRest = prepareREST();
       // ...
     }
    ERE
    Images attachées Images attachées  
    Quand une tête pense seule, elle devient folle.

  14. #94
    Membre régulier Avatar de Lideln75
    Profil pro
    Inscrit en
    Novembre 2008
    Messages
    111
    Détails du profil
    Informations personnelles :
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations forums :
    Inscription : Novembre 2008
    Messages : 111
    Points : 102
    Points
    102
    Par défaut
    Citation Envoyé par franculo_caoulene Voir le message
    C'est un bon exemple de variable qui n'a pas de sens. Avec ou sans "i", je ne sais pas ce qu'elle fait.
    Pourtant le nom possède 3 "explications" (NB : ce n'est pas une de mes variables). Si tu appelles tes variables "cetteVariablePermetDafficherLaListeDesUtilisateursConnectes", alors... Fais comme bon te semble, mais çe ne me paraît pas correct.
    On peut penser que la variable "iModeSearchSelected" indique l'ID du mode de recherche actuellement sélectionné. Tu es donc vraiment de mauvaise foi.

    Je n'ai pas parlé de cacher le code mais de le compresser. En général, il est conseillé de compresser tout ce qui ressemble à un fichier texte. Enfin si je comprends bien les recommandations de yahoo et google. La bonne pratique est donc de minifier et compresser le code javascript.
    A ce moment-là on est d'accord, mais dans ce cas-là je ne vois pas le rapport avec JS

    Je ne vois pas en quoi ton exemple montre qu'il vaut mieux utiliser l'underscore plutôt que le trait d'union. Par contre, il montre bien qu'il vaut mieux utiliser les guillemets plutôt que l'apostrophe.
    Heuuu je vois pas en quoi il montre que l'apostrophe n'est pas bonne ? Ca ne t'arrive jamais, d'escaper un caractère une fois dans ta vie ?
    Ensuite, mon exemple ne montre pas pourquoi le tiret est mauvais. Comme je l'ai dit (dis donc, tu as du mal à suivre), je ne sais PLUS pourquoi le tiret est mauvais ! L'exemple illustrait l'aspect pratique de l'utilisation du underscore.

    En PHP utiliser constamment les guillemets est une mauvaise pratique car plus lent (enfin si je ne me trompe pas, je ne suis pas développeur PHP). Je ne considère pas le fait d'insérer du code HTML comme une bonne pratique justement, mais plutôt l'utilisation du DOM.
    Non bof c'est kif kif. La principale différence est que le texte entre guillemets est parsé pour remplacer d'éventuelles variables. Donc pas bien d'écrire ses chaînes comme ça.

    A mon sens, les guillemets sont pour les balises HTML, et les apostrophes sont pour les strings. Encore une fois (bis repetita), je ne prétends pas que c'est LA façon de coder universelle, juste que ce sont des règles de développement que j'ai adoptées.


  15. #95
    Rédacteur
    Avatar de marcha
    Homme Profil pro
    Développeur Web
    Inscrit en
    Décembre 2003
    Messages
    1 571
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 53
    Localisation : Suisse

    Informations professionnelles :
    Activité : Développeur Web

    Informations forums :
    Inscription : Décembre 2003
    Messages : 1 571
    Points : 2 351
    Points
    2 351
    Par défaut
    Bonjour tout le monde,

    A mettre dans les mauvaise pratiques fréquement rencontrées:

    Ajouter du contenu dans le document
    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    document.body.innerHTML += "<p>blabla</p>";
    détruit tous les écouteurs d'évènements assignés jusqu'alors aux
    éléments existants de body
    Si ton code fait plus d'une ligne, c'est que tu as mal choisi ton langage !

  16. #96
    Modérateur
    Avatar de roro06
    Profil pro
    Inscrit en
    Avril 2007
    Messages
    1 480
    Détails du profil
    Informations personnelles :
    Âge : 54
    Localisation : France

    Informations forums :
    Inscription : Avril 2007
    Messages : 1 480
    Points : 1 978
    Points
    1 978
    Par défaut
    Bonjour

    Je vais ajouter ma sauce, car je fais beaucoup de javascript, client, mais aussi server-side.

    Pour commencer :

    Les variables

    - Utiliser des lettres minuscules et majuscules et des chiffres (abcABC012...)
    - Votre nom de variable doit commencer par une lettre, de préférence en minuscule.
    - Les espaces sont interdits , utilisez le caractère "underscore" _ à la place.
    - Utilisez la notation "Camel Case" qui consiste a utiliser une majuscule comme séparateur de mot ( exemple : faireAction ), le principe de camel case s'applique aux variables mais également aux méthode.
    Tout pareil pour moi.

    Par contre, concernant la notation hongroise, dont j'ignorais qu'elle s'appelât ainsi , je l'ai adoptée et l'utilise à tout bout de champs, cela permet de savoir immédiatement quel est l'origine de la variable. Je l'utilise pour tout, y compris pour préfixer les noms des champs de mes bases de données. Je sais ainsi instantanément qu'elle est la nature de l'objet considéré. Ainsi l'id d'un champs texte sur une page web sera préfixé par ch_, une checkbox par chk_, un select par sel_, etc...

    La ou le bas blesse, c'est que chacun y va de sa sauce ... certain utiliseront par exemple en préfixe intNPages, la ou d'autre utiliseront nbPages ou autres ...
    Oui, c'est le revers de la médaille. Il s'agit de conventions personnelles, et il suffit qu'au sein d'une équipe, les conventions adoptées soient le mêmes pour tous.

    Par contre, je vois deux écoles concernant l'indentation du codes, et particulièrement des accolades :

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
     
    function foo(){
    }
    et

    Code : Sélectionner tout - Visualiser dans une fenêtre à part
    1
    2
    3
    4
     
    function foo()
        {
        }
    Personnellement, j'adopte la deuxième, et j'ai du mal à comprendre l'intérêt de la première. Sur des scripts extrèmement longs, avec des tests, des boucles, etc ... qui prennent beaucoups plus que la hauteur de l'écran (j'ai des scripts qui peuvent dépasser les 1000 lignes sur certaines applis), je m'y retrouve mieux en adoptant la deuxième méthode, particulièrement si je dois analyser des scripts assez anciens. Qu'en est-il pour vous ?

    Pour finir :


    J'évite également addEventListener() et attachEvent() (les navigateurs reconnaissent soit l'une soit l'autre fonction), je préfère cette écriture :
    Citation:
    element.onevent = function(){mafonction()};
    Non, non, et non.

    J'ai vu sur d'autres forums que je fréquentais à une époque, beaucoup de débutants se poser la question de savoir pourquoi "dés que je rajoute un deuxième script sur ma page, le premier ne marche plus". (à chaque fois, utilisation dans chacun des scripts de window.onload, vous l'aurez deviné) L'utilisation de element.onevent écrase le premier préalablement déclaré.

    en utilisant les event listener (ou attachevent, selon le sniffeur), on peut séparer dans plusieurs scripts distincts chaque fonction, sans se préoccuper de savoir si la page chargera, ou pas, un script, deux ou pas du tout.


    N'oubliez pas de consulter les FAQ ASP et les cours et tutoriels ASP

    " La vie c'est quelque chose de très fort et de très beau.... La vie appartient a tous les vivants. It's both a dream and a feeling. C'est être ce que nous ne sommes pas sans le rester. La vie c'est mourir aussi....Et mourir c'est vraiment strong...c'est rester en vie au delà de la mort...Tous ceux qui sont morts n'ignorent pas de le savoir."
    (J.C. VanDamme, humoriste et philosophe belge . A moins que ce ne soit l'inverse ...)

    Chuck Norris comprend JC Van Damme.

  17. #97
    Nouveau membre du Club
    Profil pro
    Inscrit en
    Février 2009
    Messages
    39
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Février 2009
    Messages : 39
    Points : 38
    Points
    38
    Par défaut
    Rebonjour,

    En général, je reste sur la même position que le_chomeur.

    Concernant le reste des discussions que j'ai pu lire, chacun code à sa façon. Nous ne sommes pas ici pour forcer les personnes à utiliser uniquement des quotes ' ou des doubles quotes ", ni non plus pour forcer les futurs développeurs à utiliser JQuery... Ce ne sont plus des bonnes pratiques, mais des préférences personnelles.

    En plus, dans le cadre d'un texte bourré d'apostrophes et dénué complétement de doubles quotes, je préfèrerai largement mettre des doubles quotes autour que des simples.
    Je suis d'accord sur le fait qu'il faut en général coder uniformément pour placer de bonnes bases, mais il faudrait que ça reste pratique et faisable, et qu'on laisse encore une part de liberté au codeur.

  18. #98
    Rédacteur/Modérateur

    Avatar de SpaceFrog
    Homme Profil pro
    Développeur Web Php Mysql Html Javascript CSS Apache - Intégrateur - Bidouilleur SharePoint
    Inscrit en
    Mars 2002
    Messages
    39 634
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 74
    Localisation : Royaume-Uni

    Informations professionnelles :
    Activité : Développeur Web Php Mysql Html Javascript CSS Apache - Intégrateur - Bidouilleur SharePoint
    Secteur : Industrie

    Informations forums :
    Inscription : Mars 2002
    Messages : 39 634
    Points : 66 650
    Points
    66 650
    Billets dans le blog
    1
    Par défaut
    Juste pour relancer un peu le debat qui s'essouffle en considérations superficielles de goûts et de couleurs, je me posais la question des fonctions, j'ai utilisé un peu de tout sans jamais avoir testé les performances de chacune des syntaxes

    par exemple vaut il mieux declarer les fonctions de manière traditionnelles

    function foo(){} ( à la ligne ou pas pour les { on s'est tape )

    ou bien :

    var foo = function(){}

    ou encore en "objet" ou closures etc ...
    quels sont les avantages et inconvéniants de chacun ...
    Le peu de littérature que j'ai pu trouver ailleurs sur ce sujet était trop rebarabtive poru que je m'y attarde ...
    Ma page Developpez - Mon Blog Developpez
    Président du CCMPTP (Comité Contre le Mot "Problème" dans les Titres de Posts)
    Deux règles du succès: 1) Ne communiquez jamais à quelqu'un tout votre savoir...
    Votre post est résolu ? Alors n'oubliez pas le Tag

    Venez sur le Chat de Développez !

  19. #99
    Membre actif Avatar de nod__
    Profil pro
    Étudiant
    Inscrit en
    Avril 2009
    Messages
    176
    Détails du profil
    Informations personnelles :
    Localisation : France, Nord (Nord Pas de Calais)

    Informations professionnelles :
    Activité : Étudiant

    Informations forums :
    Inscription : Avril 2009
    Messages : 176
    Points : 226
    Points
    226
    Par défaut
    y'a eu un article très complet là dessus il y a très peu de temps justement. J'avoue que j'ai lu que les parties nouvelles donc je sais pas si il est spécialement «fun» à lire. Mais ça devrait te filer un bon coup de main dans la réponse de ces questions

    http://yura.thinkweb2.com/named-function-expressions/

    http://www.developpez.net/forums/d75...e/#post4375749 :-°

  20. #100
    Membre averti
    Profil pro
    Inscrit en
    Mars 2006
    Messages
    319
    Détails du profil
    Informations personnelles :
    Âge : 43
    Localisation : Belgique

    Informations forums :
    Inscription : Mars 2006
    Messages : 319
    Points : 351
    Points
    351
    Par défaut
    Citation Envoyé par le_chomeur Voir le message
    [...]il sera toujours appréciable et pratique de retrouver un code ( même mal codé ) commenter , qu'un code de niveau "expert" qu'il nous faudra des heures à comprendre.
    Même mal commenté ?

    La première documentation c'est le code lui même, avec des noms de symboles bien réfléchis, sans abréviations et sans aucune touche de folklore. Pas de concession là dessus. S'il manque du temps le code sera assez expressif sans documentation pour qui veut vraiment s'en servir.

    Mettre des commentaires pour mettre des commentaires ?.. Des clous ! Ça ne vaut rien. Quand on écrit un commentaire on doit se placer - et c'est assez difficile - à la place de celui qui passe par là et qui lit. Bien trop souvent on tombe sur des commentaires qui ne veulent strictement rien dire et qui, finalement, ne font que polluer l'espace visuel et, pire, perdre le lecteur.
    Le plus comique étant lorsqu'ils doivent être écrits dans une langue étrangère et que l'auteur ne la maîtrise pas. Remarquez, quand parfois on en lit en français on est tout aussi paumés...

Discussions similaires

  1. Bonnes pratiques pour la POO en Javascript
    Par piemur2000 dans le forum Général JavaScript
    Réponses: 5
    Dernier message: 05/10/2013, 16h33
  2. bonnes pratiques syntaxe javascript
    Par Invité dans le forum Général JavaScript
    Réponses: 2
    Dernier message: 27/06/2013, 11h40
  3. Bonnes pratiques de sécurité en JavaScript
    Par Toulousaing dans le forum Général JavaScript
    Réponses: 1
    Dernier message: 08/04/2012, 20h47
  4. javascript orienté objet: bonne pratique et héritage
    Par negstek dans le forum Général JavaScript
    Réponses: 9
    Dernier message: 31/08/2011, 20h27
  5. [POO] Bonnes pratiques href="javascript:fonction()"
    Par LhIaScZkTer dans le forum Général JavaScript
    Réponses: 20
    Dernier message: 04/04/2009, 19h26

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