Discussion :

[Bovino]

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

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
// fonction de calcul
function calcul(){
...
}

[Oscar Hiboux]

LOL, c'est typiquement ça !!

[le_chomeur]

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 !!

[Bovino]

:sifle:

Ce smiley n'existe pas

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 !!

Oui, je confirme

[marcha]

+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:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
 
function afficher(e) {
   e.style.display = 'block';
}
 
function masquer(element) {
  element.style.display = 'none';
}

e et element représentent la même chose et devraient avoir le même nom. Ici l'exemple
est trivial, mais je suis souvent confronté à ce problème lorsqu'il y a beaucoup de
fonctions.

[kernelfailure]

. . .
bannir document.write()
. . .

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.

Pourquoi tant de haine ?

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

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

. . .
On peut penser que la variable "iModeSearchSelected" indique l'ID du mode de recherche actuellement sélectionné.
. . .

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

[Oscar Hiboux]

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.

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.
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 ! (P.S. : j'aimais bien l'idée, ahah)

[...]"idSearchMode" (pour identifiant de mode de recherche) ou "usrSearchMode" (pour mode de recherche de l'utilisateur - donc sélectionné) seraient beaucoup plus parlant.
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.

Hmm, "idSearchMode" conviendrait mieux à "mode de recherche d'identifiant", non ?
"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é ?

[...]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'.

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.

D'ailleurs, le nom est bien plus important, "searchMode" plutôt que "modeSearch"

En effet, ahah !

[...]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'.

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 !

[kernelfailure]

Ça sert à quoi d'économiser 2 caractères pour sacrifier la lisibilité ?

Arf... On peut se poser la question.
C'est parce qu'hongrois que c'est mieux
Mais attention à l'excès inverse, où les noms sont des romans.

"instanceUser" L'utilisateur-instance ? L'utilisateur de l'instance ?

Tout simplement une instance de la classe User

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 !

Même pas besoin de caster en plus ! La mega classe !!!
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.

[Oscar Hiboux]

Même pas besoin de caster en plus ! La mega classe !!!

Ahahah, trop la classe, oui !!

Bien d'accord avec le reste aussi, c'est exactement ce que je fais. ^^

[Gruik]

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 :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

typeof objet['propriete'] != 'undefined'

Sinon mon style est globalement celui de Java.. Notamment mixedCase pour tous les identificateurs.

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

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

{ 'prop': 34, 'prop2': 'val' }

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)

[Sunchaser]

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,

[Causa Sui]

Moi, personellement, mes recomandations sont simples :

1. Ne pas faire de JavaScript (le Javascript c'est mal).
2. Utiliser JQuery.
3. 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.
4. 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).

[RomainVALERI]

[*]Ne pas faire de JavaScript (le Javascript c'est mal).

?!
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 ?
(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é ^^)

[Bovino]

1. Ne pas faire de JavaScript (le Javascript c'est mal).
2. Utiliser JQuery.

Comment tu peux utiliser jQuery sans faire de JavaScript

[Causa Sui]

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 !

[Oscar Hiboux]

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

[Causa Sui]

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

[SpaceFrog]

Comment tu peux utiliser jQuery sans faire de JavaScript

internet c'est le mal

[Oscar Hiboux]

C'est ne pas devoir se prendre la tête avec addEventListener et attachEvent, notamment.

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...
Et donc, si ce n'est pas ça, c'est quoi ?

Enfin, moi si je râle sur JS c'est surtout parce qu'un certain navigateur [...] qui trouve que « le javascript ce n'est pas le plus important » bloque l'évolution de ce langage à un stade anti-diluvien...

Question de plateforme alors, pas de langage ! 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.


P.S. : un "stade anti-diluvien", c'est un abri anti-déluge ? ^^

[pserru]

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