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. )
Version imprimable
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. )
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:
2
3
4
5
- 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:
2
3
4
5
6
7
8
9
10
11
12
- 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:
2SDefines.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 :
Bonne fin de soirée !Code:
2
3
4
5
Lideln
utilise l'objet Function() ;)Citation:
Envoyé par Lideln75
Code:
2
3
4
5
6
7
Oui enfin le constructeur Function et eval sont aussi mauvais l'un que l'autre… puisque Function appelle eval()…
la vraie soluce est :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)Code:
2
3
4
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
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)Citation:
function displayWindow(sWindowName)
{
window["Window" + sWindowName].onInit();
}
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 ;)
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).C'est exactement pareil. Donc bon bah autant l'utiliser.Code:
2
3
4
5
6
Vouloir utiliser JS comme ça c'est un problème de conception. Si tu avais par exempleTout simplement. appeler un objet "Window" c'est au mieux déroutant, vu que le contexte s'appele déjà "window"Code:
2
3
4
5
6
7
8
9
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.
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+
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 :)
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.Citation:
Envoyé par Lideln75
Que veut dire "bien commenter un code"? C'est toute une question.Citation:
Envoyé par Lideln75
On peut aussi parler de le compresser quand on peut le faire.Citation:
Envoyé par Lideln75
Je demande plus d'explications.Citation:
Envoyé par Lideln75
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
Sans oublier JSONCitation:
Envoyé par Lideln75
. . .
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 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 ...Citation:
"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”…"
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 :
pas très explicite ??Code:
2
3
4
5
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 ... )
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é).Citation:
Envoyé par franculo_caoulene
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.
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.Citation:
Que veut dire "bien commenter un code"? C'est toute une question.
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).Citation:
On peut aussi parler de le compresser quand on peut le faire.
J'ai donné un exemple en plus... Merci de relire ;)Citation:
Je demande plus d'explications.
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.Citation:
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.
Oui oui...Citation:
Sans oublier JSON
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 :)
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
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
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
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
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.Citation:
Envoyé par Lideln75
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.Citation:
Envoyé par le_chomeur
ERECode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
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.Citation:
Envoyé par franculo_caoulene
On peut penser que la variable "iModeSearchSelected" indique l'ID du mode de recherche actuellement sélectionné. Tu es donc vraiment de mauvaise foi.
A ce moment-là on est d'accord, mais dans ce cas-là je ne vois pas le rapport avec JS ;)Citation:
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 ?Citation:
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.
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.
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.Citation:
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.
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.
:)
Bonjour tout le monde,
A mettre dans les mauvaise pratiques fréquement rencontrées:
Ajouter du contenu dans le document
détruit tous les écouteurs d'évènements assignés jusqu'alors auxCode:document.body.innerHTML += "<p>blabla</p>";
éléments existants de body
Bonjour
Je vais ajouter ma sauce, car je fais beaucoup de javascript, client, mais aussi server-side.
Pour commencer :
Tout pareil pour moi.Citation:
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.
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...
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.Citation:
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 ...
Par contre, je vois deux écoles concernant l'indentation du codes, et particulièrement des accolades :
etCode:
2
3
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 ?Code:
2
3
4
Pour finir :
Non, non, et non. :nono::nono::nono:Citation:
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()};
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.
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.
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 ... :D
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 :-°
Même mal commenté ? :)Citation:
Envoyé par le_chomeur
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... :aie:
:lol:Citation:
Envoyé par Oscar Hiboux
C'est pas faux tout ça !
Effectivement, le nommage est très important, à mon avis, une variable, un paramètre etc. doivent être nommés en fonction de ce qu'ils représentent en terme de contenu, pas de contenant, par exemple, nommer une variable qui va créer une div à insérer dans le document devra plus s'appeler "ajout_documentation_article" que "nouvelle_div".
Ceci dit, les commentaires sont aussi importants, à condition d'êtres mis à jour en même temps que le code, ne serait-ce que pour soi-même ou ses collègues, mais tu as raison d'enfoncer le clou : dans la mesure ou ils sont pertinents et explicatifs !
Qui n'a jamais vu dans un code des trucs du genre :
:mouarf:Code:
2
3
4
LOL, c'est typiquement ça !! :mouarf::aie:
mouai je parle naturellement de commentaires constructif ^^
sans lancer la pierre pas comme certain de ce post :sifle:
sinon pour spaffy et sa requète sur les fonctions avancé en js , closure, héritage etc, récupère le livre que bovino a commenter il est vraiment génial !!
Ce smiley n'existe pas :langue:Citation:
Envoyé par le_chomeur
Oui, je confirme ;)Citation:
sinon pour spaffy et sa requète sur les fonctions avancé en js , closure, héritage etc, récupère le livre que bovino a commenter il est vraiment génial !!
+1 Oscar Hiboux, et les réponse suivantes.
Puisqu'on parle du nommage et du code qui devrait pouvoir être clair sans commentaires,
il y a une bonne pratique que j'essaie de respecter qui consiste à maintenir la cohérence
de nommage au travers des différentes fonctions.
Un exemple pour illustrer une incohérence:
e et element représentent la même chose et devraient avoir le même nom. Ici l'exempleCode:
2
3
4
5
6
7
8
est trivial, mais je suis souvent confronté à ce problème lorsqu'il y a beaucoup de
fonctions.
Ca fait plusieurs fois que je lis que certains expriment le désir de ne plus utiliser cette méthode sans bien comprendre leur motivation.Citation:
Envoyé par Auteur
Pourquoi tant de haine ? ;)
Je comprends mieux pourquoi aujourd'hui encore je trouve inutile l'emploie de ui32Machin ou LPTRBidule etc... La belle affaire d'avoir ce genre d'information, surtout ici, pour du javascript.Citation:
Envoyé par nod__
En revanche, l'aspect originel est plutôt intéressant. C'est bien dommage que cette notion, cette vraie utilité, ait été mal comprise et dégradée.
J'ai toujours trouvé ce 'typage' pénible, et je trouve ça particulièrement ridicule et inadapté à la programmation objet.
Simple : il faudrait inventer autant de type que d'objets.
Or la tendance est de n'accorder de l'intérêt que pour les types basiques (limité sous JS), ce qui devient un tour de force sous Python (Où tout est objet).
Justement, un simple "idSearchMode" (pour identifiant de mode de recherche) ou "usrSearchMode" (pour mode de recherche de l'utilisateur - donc sélectionné) seraient beaucoup plus parlant.Citation:
Envoyé par Lideln75
Ou pourquoi pas "idxSearchMode" s'il s'agit d'un index (selected).
Le fait que la valeur soit stipulée comme entière n'est pas d'un grand intérêt.
D'ailleurs, le nom est bien plus important, "searchMode" plutôt que "modeSearch" ;)
Mais 'i' pour 'integer' ou 'instance' ?
Oui, parce que j'ai déjà vu des 'o' pour qualifier des instances...
Donc, 'var oI = new Integer();' tandis que 'var iI = 0;' ne serait pas pareil.
Tout n'est pas noir ou blanc, et dans le genre, je trouve plutôt bien de fortement qualifier les paramètres de méthodes et fonctions, par exemple, en nommant clairement le type d'instance attendu, genre 'dateDeparture' ou 'instanceUser' ou 'amtBooking' ou 'amountBooking'.
Mais je préfère lire 'amount' que 'float' ou 'fAmount' ou 'fAmt'...
Je dirais plus : "ridicule et inadapté" surtout aux langages à types forts où il est impossible de se tromper sinon ça ne compile même pas. D'ailleurs, pour ces langages, tout bon IDE reconnait le types des entités manipulées et les colore et présente de bien belles manières. Pour les autres ça pourrait se comprendre, quand l'équipe au complet est rigoureuse (ce qui n'arrive que très très rarement). Donc inadapté ? Assez souvent, du fait du temps d'adaptation à la pratique lorsqu'un membre intègre une équipe et au temps perdu par l'incompréhension passagère dû au mauvais emploi de ces petits préfixes et la diminution de lisibilité du code assez rapidement.Citation:
Envoyé par kernelfailure
Je me souviens avoir vu passer des "xDog" dans certains projets employant ce genre de préfixes pour signifier qu'on manipulait un noeud XML... Ça peut conduire loin ! :D (P.S. : j'aimais bien l'idée, ahah)
Hmm, "idSearchMode" conviendrait mieux à "mode de recherche d'identifiant", non ? :aie:Citation:
Envoyé par kernelfailure
"usrSearchMode" ? Pourquoi s'écorcher les yeux et ne pas écrire pleinement "userSearchMode" ? Pareil, "idxSearchMode" ? "searchModeIndex", non ? Ça sert à quoi d'économiser 2 caractères pour sacrifier la lisibilité ?
Allez, dans la série... "dateDeparture", c'est le départ de la date ? "instanceUser" L'utilisateur-instance ? L'utilisateur de l'instance ? "amtBooking" ? Ah, on économise 3 caractères, hihi.Citation:
Envoyé par kernelfailure
En effet, ahah ! :mouarf:Citation:
Envoyé par kernelfailure
Pour ma part, ce que je n'aime pas trop dans ce genre de pratique c'est que ça "pollue" les noms de symboles, et je trouve tellement confortable de pouvoir réutiliser une même variable pour accueillir deux objets de type différents au fil des instructions... Aïe, pas taper ! :aie:Citation:
Envoyé par kernelfailure
Arf... On peut se poser la question.Citation:
Envoyé par Oscar Hiboux
C'est parce qu'hongrois que c'est mieux ;)
Mais attention à l'excès inverse, où les noms sont des romans.
Tout simplement une instance de la classe User :mouarf:Citation:
Envoyé par Oscar Hiboux
Même pas besoin de caster en plus ! La mega classe !!! :mouarf:Citation:
Envoyé par Oscar Hiboux
C'est un confort que j'emploie très souvent lorsque la portée est locale et/ou la durée de vie est courte.
Mixed est un type très puissant. Le polymorphisme absolu : Tout est Object.
Ahahah, trop la classe, oui !! :mouarf:Citation:
Envoyé par kernelfailure
Bien d'accord avec le reste aussi, c'est exactement ce que je fais. ^^
Hello,
A un moment, j'ai pas mal utilisé http://www.jslint.com/ , ça a influencé mon style d'aujourd'hui.
Aussi, je voulais à cette meme époque avoir 0 warning firefox en mode strict (mais c'est plus vraiment possible vu que j'utilise tout le temps jQuery, qui en contient pas mal).
Donc la technique que j'utilisais et que j'utilise encore pour tester si une propriété existe est :
Sinon mon style est globalement celui de Java.. Notamment mixedCase pour tous les identificateurs.Code:typeof objet['propriete'] != 'undefined'
Je plussoie ce qui a été dit pour "var" : faut toujours déclarer ses variables. En dehors de toute fonction par contre, je déclare pas de variable, j'utilise les propriétés de window (ce qui est globalement la même chose mais bon).
Pour la construction d'objets (notation JSON), je mets toujours le nom de la propriété entre quotes
Sans parler du style du code, il ya une bonne pratique adoptée par presque tous qui consiste à ne pas creer de gestionnaires d'évenements avec les attributs html (ex : <a onclick="...">), toujours les attacher indirectement (exemple : quand le DOM est prêt)Code:{ 'prop': 34, 'prop2': 'val' }
Bonjour,
Je me permets d'intervenir (dans ce post que je suis - du verbe suivre évidement - avec attention), non pas pour une recette particulière ou "magique" a appliquer mais pour une question ...
En remontant vers la page 2 ou 3, on y parlais de test de performance entre des boucles for / while (cf le post de franculo_caoulene et son idée d' "imax" que j'ai adopté, merci); je me disais donc "y a t il qqchose de particulier a propos du switch" ? Je suis gourmand en switch mais je me demandais si lui n'était pas "gourmand" et/ou si il n'y avais rien de particulier a son sujet chez javascript.
Cette question est peut être niaise, mais sait on jamais ...
Ca ne va pas faire avancer le schmilblick, mais je ne peut m'empêcher de m'étonner lorsque je vois toutes les recommandations: par ex, je connais un système extrèmement onéreux (et pas vieux) dont le javascript de l'interface web a gardé ses petits "document.write", "innerHTML=...", et autres "<a onclick=...>".
Ca m'épate.
Merci d'avance,
;)
Moi, personellement, mes recomandations sont simples :
- Ne pas faire de JavaScript (le Javascript c'est mal).
- Utiliser JQuery.
- Sinon, tout à déjà été dit : ne JAMAIS inclure le code JS dans l'HTML (non, non, jamais, sinon vous finirez en enfer), utiliser les gestionnaires d'évènement modernes (et pas ces monstruosités de onXXX), définir les variables, utiliser le DOM (ou mieux : E4X), etc.
- Et le plus important - je ne sais pas si ça a déjà été cité : ne jamais faire reposer une fonctionnalité uniquement sur JS, et toujours prévoir une dégradabilité du code (sauf dans certains cas de site clairement orientés applications).
:? ?!Citation:
Envoyé par Causa Sui
Je ne parviens pas à deviner à quoi tu fais référence... quel est le problème avec JS ?
Tu peux... *développer* s'il te plait ? :mrgreen:
(quitte à créer un nouveau thread pour ne pas "troller" sur celui-ci, au thème légèrement différent et déjà bien chargé ^^)
8O8O8OCitation:
- Ne pas faire de JavaScript (le Javascript c'est mal).
- Utiliser JQuery.
Comment tu peux utiliser jQuery sans faire de JavaScript :koi:
Le Javascript est un langage très énervant parce que très en dessous de ce qu'il pourrait être. Le jour où on sera au même niveau avec JS qu'avec l'ActionScipt (E3X par défaut, gestions des événements unique, gestion des erreurs unifiées, possibilité d'utiliser un typage plus fort etc.) ce sera vraiment plaisant à utiliser.
Donc, j'aimerais ne pas devoir faire du JS tel qu'il est maintenant, mais si j'en fait... c'est avec JQuery !
Bah... c'est presque hors sujet ton affaire. On n'est pas la pour faire de la pub supplémentaire à J. Resig... ^^'
E4X c'est bien marrant mais question clarté on a connu mieux. Soit dit en passant, tant qu'on parle de bonnes pratiques : quant il s'agit de manipuler des données autant utiliser JSON, c'est un chouïa plus facile et performant (!). Sauf cas de scripting du côté serveur (Jaxer & co.) on peut quand même se passer d'XML du côté client...
JavaScript est très plaisant, sisi, mais même si c'est une question de goût tu risques quand même le lancer de tomates pourries en venant le dire ici... :aie:
Sinon, pouvoir utiliser un typage un peu plus fort comme en ActionScript ça serait bien chouette, en effet.
C'est quoi la "gestion des événements unique" ?
C'est ne pas devoir se prendre la tête avec addEventListener et attachEvent, notamment.
Enfin, moi si je râle sur JS c'est surtout parce qu'un certain navigateur d'une certaine marque dont je ne citerai pas le nom (je vais pas lui faire de la pub en plus) qui trouve que « le javascript ce n'est pas le plus important » bloque l'évolution de ce langage à un stade anti-diluvien...
(et quand je dis JQuery, c'est également valable pour tous les framework de qualité qui facilitent la vie des développeurs, je ne suis pas sectaire, mais c'est celui que j'utilise le plus).
internet c'est le mal :mouarf:Citation:
Envoyé par Bovino
Hmm, et tu procèdes comment alors ? addEventListener & co. (mieux vaut utiliser un framework pour la gestion des événements, en effet) c'est en plein le concept d'observateur, je vois mal comment on pourrait l'éviter. Il faut quand même bien l'indiquer quand tu veux suivre les événements sur un sujet donné. L'ordinateur n'est pas devin non plus... 8OCitation:
Envoyé par Causa Sui
Et donc, si ce n'est pas ça, c'est quoi ? :D
Question de plateforme alors, pas de langage ! :mrgreen: Mais c'est vrai, c'est très frustrant par moment... La lueur à l'horizon c'est que si Microsoft ne se réveille pas rapidement ils vont se prendre une méchante claque dans les prochaines années - j'espère.Citation:
Envoyé par Causa Sui
P.S. : un "stade anti-diluvien", c'est un abri anti-déluge ? ^^
Bonjour,
Un des problème classique est la présence de code de déboguage dans la version en production. Ceci est vrai pour bien des langages, bien qu'en JavaScript... Je suggère de n'utiliser la première colonne que pour du commentaire** ou ce type de code. Ceci permet un repérage rapide pour le développeur, et une détection facile pour votre logiciel de compactage/installation sur site de production.
** Et encore! Acceptable parce que vous voulez passer en commentaire votre ligne de code de déboguage.
Bon courage,
Patrick