Le Javascript, ce n’est pas automatique !

Ces dernières années, le javascript et ses bonnes pratiques ont énormément évolué.

Ecrire son javascript, recharger la page (« vide ton cache ! »), prier que le javascript fonctionne et que l’on n’a rien oublié (un ;, une variable mal nommée), recommencer… recommencer.. recommencer… essayer les autres navigateurs, et continuer jusqu’à éradiquer toutes les erreurs.

Ah quelle joie le code javascript et le travail ‘artisanal’, enfin, cela, c’était AVANT.

Découvrez les outils du moment pour vous concentrer sur l’essentiel et coder plus efficacement !

Le Linter : pour un code plus propre !

Qu’est ce qu’un linter ? C’est un outil qui va vérifier la syntaxe de votre javascript (l’oubli d’un break, l’utilisation d’une variable inexistante), mais qui va veiller aussi au respect de certaines normes et bonnes pratiques d’écriture éprouvées pour contrer la permissivité du Javascript.

Mine de rien, cela fait gagner énormément de temps, en vous évitant de lancer le navigateur et de vous retrouver avec une erreur d’inattention.

Les éditeurs de texte intègrent maintenant ce genre de plugins, ne vous privez pas de ce bonheur.

JSHint : les bonnes pratiques

JSHint gère toutes les erreurs qui risqueraient de planter directement sur votre navigateur.
Une variable utilisée avant sa déclaration, un break ou return oublié, une virgule en trop, toutes ces petites règles.

Il vérifie aussi que l’on utilise les bonnes pratiques afin d’éviter des comportements inattendus :

  • il est bon de rajouter 'use strict' dans son code afin d’éviter que l’on puisse automatiquement utiliser dans une méthode une variable du même nom qu’une variable déclarée dans une méthode parente (ah la surprise des méthodes imbriquées utilisant la même variable de leurs boucles for) ou au global.
  • le == est mort, utilisez les comparateurs === et !==, qui saurons faire la différence entre « 1 », 1 et true ! Après le raccourci est parfois plus pratique mais apprendre aux juniors que true == 1 n’est pas la meilleure des idées…
  • JSHint vous alertera si vous avez oublié un return ou un break, c’est le genre d’inattentions qui peuvent coûter cher en debug inutile

Si certaines règles vous ennuient, rien ne vous empêche de précéder votre code avec certaines instructions comprises par JSHint et que vous trouverez dans leur documentation.
Ainsi l’instruction /*global window:false, document:false, $:false */ vous permettra d’utiliser les objet window, document et $ (jQuery) en lecture seule (d’où le false) sans être alerté.

Personnellement, j’ai choisi JSHint, car je le trouve juste sans être contraignant.

JSLint : le Maître Cappello

Si vous voulez que votre code soit plus clair, correctement indenté et ne risque aucune confusion pour les néophytes, vous pouvez vous frotter à JSLint, qui est intransigeant et contraignant.

Votre mission, si vous l’acceptez, sera de mettre aux normes toute votre indentation, les espacements entre les mots, la gestion des retours à la ligne etc.. etc..
Si vous réussissez l’exercice, d’une vous en sentirez une certaine satisfaction, de deux la forme de votre code sera carrée, inattaquable, mais surtout cela aura été un excellent exercice.

Si vous voulez en savoir plus, c’est à vos risques et périls ;).

Voir plus en détails (vous êtes prévenus !)  

L’erreur « Combine this with previous ‘var’ statement »

Si vous rencontrez cette erreur, c’est parce que vous n’avez pas regroupé toutes (oui toutes, même vos for i.. ) les variables en début de votre méthode.
Car de toute façon après compilation c’est ce que javascript fera :

function() {
 ...
 var i = 0;
}

sera traduit par javascript ainsi :

function() {
 var i;
 ...
 i = 0;
}

Eh oui la variable est réellement déclarée au tout début de la méthode, vous pouvez essayer, déclarer un console.log(i) avant la déclaration de i renverra undefined, sans produire d’erreur.

Cette façon de faire vous permettra de vous familiariser avec le moment réel de déclaration des variables, et perturbera moins le néophyte (par exemple si avant de déclarer une variable locale il tente d’accéder à une variable globale du même nom, il y’aura incompréhension…).

L’erreur Unexpected++

Moi même je n’ai pas compris pourquoi cette notation devrait disparaître selon le linter.
Mais pour un néophyte, cette notation peut être confuse, car nous n’avons pas là une seule instruction, mais deux instructions en une !.
Ils ne savent pas qu’il y’a une nette différence entre n++ et ++n, que dans le premier cas l’affectation n = n + 1 se fait après l’affichage, à l’inverse du second cas !

Il est préférable d’écrire le tout sur 2 lignes et d’écrire à la limite n += 1; ça augmentera la lisibilité, nous ne sommes plus à une ligne près, d’autant que maintenant le code ça se minifie.

ESLint : l’alternative à JSHint

Je n’ai pas personnellement testé ESLint, mais j’ai lu de son auteur qu’il l’a créé parce que JSHint ne lui permettait pas de faire ce qu’il voulait sur ses projets.
ESLint fonctionne en modules, et on peu donc lui rajouter de nouveaux modules non-prévus par la documentation initiale, c’est sa force par rapport à JSHint.

Sans configuration spéciale, la différence entre ESLint et JSHint reste finalement minime.

L’isolation, protéger son code des conflits !

Avant, on écrivait son code à la volée, et ça ne nous posait pas de souci, en même temps les librairies comme jQuery etc.. n’existaient pas.
Et du coup les conflits n’étaient que peu nombreux.
Maintenant il est courant d’utiliser plusieurs plugins pour un même site.

Vous pouvez éviter que votre code n’interfère ou soit interrompu par des plugins par la technique d’isolation, je vous le conseille d’ailleurs très fortement si vous voulez coder vous même votre plugin.

Pour isoler votre code c’est facile :

(function (window, undef) {
   'use strict';
   /* ... Votre code est maintenant isolé ... */
}(window));

En entrée votre méthode attendra que vous entriez les variables globales attendues (ici window), plus une dernière variable qui ne sera pas remplie, afin que dans nous ayons un équivalent à undefined dans notre code.
Ainsi ici rien ne nous empêche d’écrire if (x === undef) { }, ce qui est plus plaisant que d’écrire (typeof(x) === ‘undefined’).

L’instruction 'use strict'; permet d’empêcher que vous puissiez utiliser une variable déclarée en global.
Voilà pourquoi vous devez déclarer ces variables dans votre appel, si vous voulez utiliser window, document, jQuery ou $, il vous faudra les rajouter à votre déclaration.

Si finalement il vous est vraiment nécessaire de créer une nouvelle variable globale (en êtes-vous sûrs ?), n’abandonnez pas cette manière de faire, il vous reste une parade ‘propre’ :
l’instruction window['ma_variable_globale'] = 'mavaleur'; créera une nouvelle variable globale ma_variable_globale.

La minification, facile

« minify », « uglify », vous avez déjà peut être rencontré ces termes, c’est l’action de réduire un javascript à une seule ligne avec des variables illisibles (sauf pour la machine), cela prend moins de place à télécharger, et ce sera moins facile de copier votre code.

Il existe des outils pour minifier votre javascript manuellement, mais on oubliera toujours à un moment de la lancer, alors il faut automatiser la minification.

Regardez auprès des plugins de votre éditeur de texte, vous trouverez bien votre bonheur.
Par défaut ils créent automatiquement le fichier minifié à côté du votre en rajoutant .min à son nom (votrescript.min.js), mais certains plugins proposent une configuration très avancée et permettent même d’unir plusieurs scripts en un.

Pour les plus grosses équipes, la validation et l’automatisation globale et unifiée des Javascript avec Brunch, gulp ou grunt est recommandée, d’autant que ces outils gèrent aussi l’automatisation des Css.

A vous de voir selon votre convenance.

Bien choisir son éditeur de texte

Même les éditeurs gratuits, Notepad++, SublimeText, ou Brackets, possèdent un système de plugins, au travers desquels vous trouverez de quoi avoir un linter, une minification ou même une isolation automatique !

N’hésitez pas à fouiller plutôt que de vous contenter des paramètres par défaut 😉

Notepad++/PSPad les basiques incontournables

Si vous avez commencé à coder depuis des années, ces noms là vous disent forcément quelque chose.
Moi même j’utilise encore Notepad++ pour éditer mes fichiers textes, ou pour coder sur un fichier unique.

Ils n’ont pas tant évolué que ça, mais ils restent efficace, aussi bien en mémoire qu’en rapidité, avec quelques plugin, on peut dire qu’ils font le café, même si au bout d’un moment le besoin de passer à la vitesse supérieure se fait ressentir.

SublimeText, celui qui a fait ses preuves

Je ne connais pas SublimeText, faute de l’avoir personnellement testé, il possède d’énormes atouts, notamment en terme d’efficacité et d’édition.
L’écriture devient beaucoup plus rapide pour quelqu’un qui connait les raccourcis, la recherche interne rapide, l’édition splittée simultanée.

Ne vous arrêtez pas au fond noir, qui peut être facilement changé via les thèmes.
N’hésitez pas à essayer SublimeText (à moins que je ne vous convainque d’essayer Brackets 😉 )

Brackets le nouveau qui bouscule tout

Cet éditeur date de 3 ans, et est propulsé par Adobe (oui oui).
Il facilite tout autant l’édition du javascript que l’édition html à l’instar d’un dreamweaver.
Malgré sa relative jeunesse, il a déjà tout pour plaire, notamment deux gros avantages :

  • la prévisualisation en live (avec chrome) ! On modifie un fichier, et hop la page se recharge de manière invisible, merci !
  • l’édition ‘inline’ des méthodes : votre script appelle une méthode d’un autre javascript, cliquez sur le nom de la méthode, faites Ctrl E et hop, une popin s’ouvre et vous permet d’afficher/éditer directement la méthode en question, sans avoir bougé de votre fichier actuel. Génial non ?

JSLint est déjà intégré mais peut être changé, et la communauté propose énormément de plugins, des plus efficaces aux plus complets.
Sans compter sur la possibilité de récupérer les styles depuis les PSD, parlez en à vos amis designers ! (surtout que l’édition inline fonctionne aussi pour les classes de style CSS !).

Je vous laisse vous faire une idée sur le site officiel de Brackets

Visual Studio, l’interface des ‘vrais codeurs’

Vous faites du C# pour le plaisir de la compilation, vous ne pouvez pas vous passer de cette interface merveilleuse et réactive qu’est Visual Studio, et c’est tant mieux !

Vous pouvez toujours vous permettre d’éditer directement vos javascripts depuis Visual Studio qui intègre son linter depuis la version 2015.
Mais rien ne vous empêche d’aller chercher dans les packages NuGet un autre linter ou de récupérer un minifier, d’autant que ces packages seront directement intégrés au projet et vous les partagerez donc naturellement avec votre équipe.

Merci de m’avoir suivi

N’hésitez pas à partager cette news si elle vous a plu.
Si vous avez besoin de conseils ou de mes services, n’hésitez pas à me contacter, c’est mon métier.