Comment débugger un code Javascript
En ce moment je ne fous vraiment plus rien sur mes projets, en fait je n’ai tout simplement pas la motivation (et ça m’énerve parce que les idées arrivent en masse). Dès que j’essaye de me mettre à coder je perds toute envie et je pars jouer à TF2. Y’a des périodes comme ça… ça m’est déjà arrivé et ça arrive aussi à d’autres. Bref, en ce moment je suis en mode flemmard.
Donc, vu que je n’ai rien à vous raconter sur ce que je fais (je joue, ça vous intéresse pas trop je suppose ^^’ ), j’ai décidé de sortir un petit article sur comment débugger un code en Javascript parce que je vois souvent pas mal de gens sur le forum du SdZ qui disent que “ça ne marche pas”. Oui, c’est bien, mais un peu plus d’infos et de recherche ça serait mieux non ? Si j’avais appelé le SdZ à la rescousse pour chacun de mes problèmes, j’en serai encore à coder le prototype de Sliding Menu…
Il faut savoir être un minimum autonome les gens ! Plein de solutions existent pour debugger un code, et parmi elles se trouvent des moyens très simples. Voici les principales :
- La console de votre navigateur : Non, la console n’est pas là pour faire joli sur votre bureau de geek, elle sert réellement à quelque chose ! Si je prends Firefox pour exemple, la console liste les erreurs de style CSS rencontrées mais aussi les erreurs de syntaxe dans votre code JS. La première chose à faire quand votre code ne fonctionne pas c’est de jeter un coup d’oeil à la console (elle est généralement accessible sur tous les navigateurs dans le menu des outils ou bien en mode développeur).
- Utiliser la fonction alert() : Généralement, si on a rien dans la console et que le code ne fonctionne toujours pas, c’est à cause d’une valeur erronée. Quand je parle de valeur erronée, je veux désigner par là tout ce qui concerne les variables. Imaginons que vous ayez une variable permettant de spécifier la position d’un DIV mais que celui-ci ne soit finalement pas à l’endroit auquel vous vous attendiez. Est-ce qu’il s’agit alors d’une erreur de CSS ou bien d’une erreur de JS ? Pour vérifier cela il vous suffit alors d’afficher la valeur que vous avez attribué à la position de votre DIV à l’aide d’un alert() et vous serez très vite fixé car si c’est la bonne valeur, il s’agit alors d’une erreur de CSS, dans le cas contraire il s’agira très probablement d’un mauvais calcul pour cette valeur.
Le alert() est aussi très pratique pour vérifier si une condition s’est bien exécutée, il vous suffit de placer un alert() avec un message de votre choix dans la condition et si il est affiché alors la condition a bien été exécutée.
Toutefois, le alert() a un défaut en ce qui concerne la lecture de variables : il ne peut pas être utilisé dans une boucle qui se répète de trop nombreuses fois. Pour cela il y a une autre façon de faire décrite ci-dessous. - Afficher les valeurs directement dans le HTML : C’est “on ne peut plus bête”, il vous suffit de créer une balise de type SPAN (ou autre, au choix), de lui attribuer un id et d’y afficher les valeurs souhaitées. Simple, mais efficace. Généralement, j’utilise cette méthode quand je veux afficher le contenu d’une variable qui se trouve dans une boucle ou bien dans une fonction exécutée par un setInterval().
- Utiliser un debugger : Bon, cela est réservé à des besoins assez particuliers. Certaines personnes utilisent le debugger pour lire les valeurs de leurs variables pendant l’exécution du code mais je trouve ça parfaitement inutile, un bon vieux alert() est bien plus efficace ! En revanche, l’utilité d’un debugger se révèle lorsqu’il s’agit d’analyser du DHTML car si vous modifiez votre page web à l’aide du JS, le nouveau code HTML ne sera pas accessible, or le debugger, lui, sait afficher ce code modifié. Si vous souhaitez avoir un debugger sous Firefox, il vous faudra utiliser le plugin Firebug (perso, je préfère utiliser le debugger intégré à Chrome).
- Demander de l’aide sur un forum : Oui, je le mets en dernier car on demande de l’aide quand on ne trouve pas et non pas quand on a la flemme de chercher ! Mettez-vous bien ça dans le crâne : le forum c’est le dernier recours à utiliser !
Personnellement, quand j’aide sur un forum, je le fais pour quelqu’un qui a envie de progresser et non pas pour un type qui veut qu’on lui finisse son code alors qu’il se tourne les pouces.
Voilà pour ma petite liste qui, autant le dire, n’aura pas servi aux habitués du Javascript. En revanche, j’espère avoir aidé certaines personnes qui débutent à mieux comprendre comment trouver leurs erreurs. Certes, c’est pas toujours très simple de les trouver mais c’est tellement plus enrichissant de le faire soi-même =)
À noter que tout ce que j’ai écrit ne s’applique pas uniquement au Javascript mais aussi à beaucoup d’autres langages (même pour la programmation logicielle), il suffit juste de modifier les méthodes d’affichage.
Nes’
Cool ! un truc qui va m’aider =) .
Faut seulement que je m’applique un peu plus dans le JS x)
Bon j’ai pas encore eu le courage de me mettre au JS. Je pense aussi que de tout les codes JS que j’ai vu y en pas un seul qui ai été codé d’un façon claire (Je pense surtout a toutes les variables d’une lettre qu’il y a des fois). Mais comme j’envisage de mettre bientôt, ce petit article me sera bien utile dans le futur (plus ou moins proche selon la date de sortie de la MAJ TF2 :D)
Il m’arrive de mettre des variables d’une lettre mais se sont seulement des compteurs pour des boucles, sinon j’utilise des mots explicites =)
Bon courage pour ton apprentissage ;)
Pour les variables, ce sont souvent des compteurs pour ma part. Ou alors des tests pour moi que je met de coté. Sinon, c’est souvent du à la compression des fichiers JS…
Pour la flemme, bienvenu dans le club \o/
Mince, c’est peut-être toi qui m’a contaminé, je suis aussi en mode flemmard :-° (Mais moi je joue à M&B et à Bouboum)
mode flemmard aussi depuis qq semaines :/
Ça me rassure de ne pas être seul, ça doit être l’hiver qui fait ça : les geeks hibernent =°
J’aillais le dire x).
Je veux mais ne peux pas formater mon ordi (pourtant, y a plus que quelques fichiers…)
J’ai arrêté tout apprentissage, je lis rien, je fais rien, je vais au lycée, je reviens, je regarde un épisode de John Doe, ou je fais une partie HL²DM puis je dors, je dors trop…
J’entends trop de musique…
C’est peut être parce que j’aime pas le froid -_- …
De ^m, j’hiberne, je fais mes devoirs à 1heure du mat quand je les fait, je dors sinon, je joue à Urt (petit budget) et je fous rien. Je lis ^m plus.
Et puis t’écris même pas les mots en entier x) .
Bon, c’était pour dire que le alert c’est le mal quand même, parce que c’est… pas propre, j’oublie toujours de les enlever, des fois je sais plus lequel c’est ni à quoi il sert, pour connaitre les valeurs des var, un debugger c’est génial.
Voilà
Boarf, si tu te fais un cahier des charges alors y’a aucune raison de ne plus savoir à quoi sert tel ou tel alert(), il te suffit de regarder dans ton cahier et si y’a un alert() en trop dans ton code eh bien tu le vires.
Mais pour ça il faut faire un cahier des charges =°
Et puis avoir besoin d’un debugger pour voir les valeurs des variables je trouve que c’est vraiment de l’assistanat… Placer un ou deux alert() c’est quand même pas bien dur non ? Et puis si tu as peur de les oublier, tu mets un commentaire sur la même ligne spécifiant que c’est à supprimer.
Oui, mais c’est barbare en plus, surtout que c’est le coup à placer l’alert dans une boucle, enfin voilà x)
Et je me fais des cahiers des charges ! NA !
Hého, j’ai écris quoi là ? =°
“Toutefois, le alert() a un défaut en ce qui concerne la lecture de variables : il ne peut pas être utilisé dans une boucle qui se répète de trop nombreuses fois.”
J’ai bien spécifié que le alert() était pas top pour les boucles, et pour ça je propose une autre solution.
Oui, mais là ça te bloque plus le script donc :-° . Enfin bon, tu ne peux pas comprendre la powerfullité d’un debugger, en plus ça me dépayse pas du C/C++ :) . Surtout qu’un alert pour explorer un objet :-° …
Tu as oublié aussi dans ta liste l’étape “réfléchir”, très importante et souvent oubliée…
“Oui, mais là ça te bloque plus le script donc :-° .”
J’ai jamais eu aucun problème de ce côté là, suffit de lire rapidement =°
(Je déconne hein)
Yop Nes’ ! :)
Première fois que je viens ici, et agréablement surpris en lisant tout ça. Je crois que je reviendrai. ^^
Soit dit en passant, j’adore la musique du dewplayer ! Je l’ai récupérée. :P
Voili voilou. A bientôt sur SdZ et surement ici.
Tchô !
Je suis content que mon blog te plaise, reviens quand tu veux ^^ .
Au passage, la musique du Dewplayer est régulièrement changée, tu auras de quoi écouter =p
Je sais pas, un bon
console.log();est très pratique, et moins gênant qu’alert();surtout dans une boucle ou lorsque l’on veut vérifier plusieurs valeurs sans être bloqué par ces boîtes intempestives !Tu marques un point ! Il est vrai que le console.log() est un poil plus pratique, mais à l’époque je ne connaissais pas encore cette fonction ^^ .
Là je ne vais pas modifier l’article, je laisse tel quel. Mais quand le SdZ aura enfin mis au point son système d’articles alors j’en rédigerai sûrement un sur le même sujet, j’y parlerai alors du console.log().
Une alternative rapide et utile à l’alert : le document.title.
Bien utilisé, il peut contenir pas mal d’informations utiles. Et on peut regrouper plusieurs appels successifs sur la même ligne avec la concatenation (tandis qu’on ne peut pas faire plusieurs alerts sans avoir plusieurs fenêtres).
Beh console.log() c’est supercoul. Je ne sais pas ce qu’il en est avec tous les navigateurs mais quand on fait console.log(object) avec google chrome il renvoi tout l’objet et on peut « explorer l’objet » dans la console, et ça, c’est énorme =) .