J’ai récemment eu le plaisir d’être orateur à Sud Web 2013, au titre d’un élaboratoire intitulé Internationaliser son JavaScript, un sujet qui me tient à cœur mais qui est hélas très peu traité pour le moment.

Déjà que les développeurs prennent rarement soin d’internationaliser (correctement) leurs sites web côté back, mais alors côté front, c’est un véritable désert… Même les « gros du Web », tels que Google, PayPal, e-Bay, Twitter, Facebook et consorts font montre d’un certain laxisme (voire d’un laxisme certain) sur ces sujets.

La première étape, c’est d’admettre qu’il y a un problème, comme disait l’autre. À partir de quoi, il faut savoir que nombre d’outils et de technos existent, et qu’avec un peu de professionnalisme et de bonnes pratiques on peut fournir une expérience parfaitement globalisée sur de multiples locales (contextes culturels et linguistiques).

Sensibiliser au problème et faire le tour de la question était tout l’objet de cet élaboratoire, dont les slides sont consultables en ligne.

Enjoy!

Ceci étant dit, c’est l’occasion de faire le point sur l’évolution de notre activité de formation. Et comme Attitude, c’est avant tout la transparence, je me suis dit que ça pourrait vous intéresser de voir d’où nous sommes partis et où nous en sommes.

(note : cet article est posté sur l’ensemble des sites Attitude)

Pratiquement 3 ans

Si Delicious Insights n’existe que depuis août 2011, notre activité de formation a démarré bien avant cela, sous d’autres formes : dès le 2 juillet 2010, pour être précis. C’était la première formation Git au Quotidien, déjà chez Clever Age et à un tarif ubuesque pour les valeureux pionniers qui osaient l’aventure : 50€ la journée, déjeuner compris !

Lorsqu’en octobre j’expliquais l’idée derrière Git Attitude aux copains pendant Paris Web, ce bon vieux Jérémie Patonnier m’a dit sur un ton débonnaire et détaché : « mais pourquoi tu ne fais pas la même chose avec JavaScript ? ». Après m’être tapé la tête contre le mur de ne pas y avoir pensé dès le début, j’ai donc lancé JS Attitude avec tout d’abord JS Puissant et une première session bondée (16 personnes !) le 27 novembre, vendue en quelques jours, presque quelques heures…

Voici un petit historique de jalons sélectionnés :

Quelques chiffres

Je vous passe l’évolution d’un exercice fiscal à l’autre, mais sachez qu’aujourd’hui, Delicious Insights, au travers de Git Attitude et JS Attitude, c’est :

• 7 formations au catalogue (3 Git et 4 JavaScript)
• 52 sessions déjà données, soit
• 544 heures de formation à destination de
• 444 stagiaires au sein de
• plus de 80 sociétés clientes (et de nombreux participants à titre personnel)

Parmi nos clients, un équilibre surprenant entre TPE/PME, agences (TBWA, MRM Worldwide, Fullsix / Ekino…), SSII (Atos, Valtech…) et grands comptes (SNCF, Orange, EADS, Dassault, Intel, Alcatel-Lucent, 4D, FNAC, l’OCDE, Météo France, MisterGoodDeal, PriceMinister…). Des clients situés dans 5 pays : France, Royaume-Uni, Belgique, Suisse et Luxembourg.

Des stagiaires enchantés

Tous nos stagiaires ont l’occasion de faire un retour à chaud en fin de session, face à face, ainsi qu’un retour à froid via un formulaire en ligne proposant des évaluations tant quantitatives (notes de 1 à 5) que qualitatives (texte libre). Un bon tiers de nos stagiaires prennent le temps de le remplir (une proportion historique qui, toutefois, ne cesse de s’améliorer). Nous n’avons rien à cacher, alors allez donc consulter un rapport temps réel sur les retours qui nous sont faits.

Merci à vous

Je voudrais profiter de cet article pour remercier très chaleureusement tous les stagiaires qui nous ont fait confiance jusqu’ici, et leurs employeurs qui ont accepté de les envoyer dans nos formations. C’est un plaisir chaque fois renouvellé de vous transmettre tout ce qu’on peut, d’échanger avec vous et de lire vos retours !

Et maintenant ?

Eh bien, on va commencer par finir l’exercice en cours (au 30 juin), et préparer la rentrée…

Je souhaite rédiger davantage d’articles de fond, ainsi que de la retranscription de veille et des didacticiels sur diverses technos, sur les différents sites Attitude.

J’ai très envie de pouvoir mettre au catalogue des formations Node.js, Ruby et Rails, mais on verra si le temps de préparation ne fait pas trop défaut.

On va probablement élargir petit à petit le groupe de formateurs, aussi, en travaillant avec des personnes de confiance qu’on connaît de longue date, qui partagent notre philosophie, nos valeurs, et font preuve d’une expertise technique et d’une pédagogie à la hauteur de nos exigences.

Enfin, le catalogue de formations va faire l’objet au fur et à mesure d’une déclinaison sous forme de screencasts qualitatifs payants, d’une heure environ chacun, avec des possibilités d’achat par lot (pour toute la série “Git au Quotidien” par exemple), les stagiaires bénéficiant automatiquement d’un fort rabais sur ces derniers.

Espérons qu’on aura le temps de tout faire !

Si vous avez suffisamment de personnes demandeuses dans votre entreprise, vous pouvez nous contacter pour une JS Total en intra-entreprise ; on n’a plus de place sur mai et juin mais si vous le souhaitez, on peut faire ça en juillet ou août (au mépris de la sacro-sainte stupeur-tout-l’été si française).

Dans le cas contraire, je ne saurais trop vous encourager à prendre la meilleure option restante : une JS Puissant suivie d’une JS Guru. Ces deux sessions correspondent à peu près aux journées 1 et 3 de JS Total, et sont donc très intéressantes. Qui plus est, vous aurez le temps de « digérer » JS Puissant pendant 3 semaines avant d’attaquer JS Guru.

Chacune n’a en effet plus qu’une date avant l’été :

• JS Puissant mardi 30 avril 2013 (c’est très bientôt !)
• JS Guru mardi 21 mai 2013 (non, cette semaine-là ne contient pas de pont, on a vérifié…)

La session du 30 avril manque actuellement d’une personne pour atteindre son quorum minimal de participants, je vous invite donc à faire établir votre convention au grand plus tard mardi 23, histoire de garantir la date !

Parmi les retours en ligne effectués sur ces formations, on trouve par exemple :

Waouh ! Cool ! C’était trop bien :-) … et merci ! Merci beaucoup de partager ainsi toute cette connaissance. On a juste envie en sortant de là, de s’y mettre à fond, d’approfondir encore plus les choses et de ne plus pratiquer que le JS ! C’était passionnant !

Vraiment très bien. Je vois javascript différemment maintenant. Il s’agit d’un langage puissant quand on l’utilise bien.

La meilleure formation [que j’aie] jamais faite, toutes technos confondues ! À recommander à toute personne désirant s’améliorer en JS.

Super formateur qui m’a boosté pour les 100 prochaines années, super passionné !! Que du +++

Je trouve que cette formation était excellente de bout en bout. […] Merci à toi Christophe pour cette formation dynamique et passionnante !

Et encore, on en passe plein…

Dépêchez-vous !

C’est assez navrant, mais pas vraiment surprenant, vu les travers habituels du secteur des « nouvelles technologies » en France, lequel—à l’exception de trop peu d’individus aussi brillants que passionnés, dont vous êtes certainement—a toujours marqué une ironique aversion envers tout ce qui est effectivement nouveau.

Laissez-moi donc vous expliquer brièvement pourquoi CoffeeScript est important, et pourquoi votre avenir passe par lui ou, tout du moins, s’en inspire.

CoffeeScript, qu’est-ce que c’est exactement ?

CoffeeScript est « le petit langage qui compile vers JavaScript ». Il s’agit d’un langage de plus haut niveau, créé et principalement maintenu par l’excellent Jérémy Ashkenas (qui nous a aussi donnés, entre autres, Backbone et Underscore ; ça se pose là, comme historique…).

Alors que chaque jour JavaScript devient un peu plus une machine virtuelle (VM) pour le web, dont les performances s’approchent de plus en plus vite du natif (et parfois même le dépassent), les langages qui « compilent vers JavaScript » sont de plus en plus nombreux, comme en témoigne AltJS.

CoffeeScript est de loin le plus populaire : alors que JavaScript est le langage n°1 sur Github (21% des projets à l’heure ou j’écris ceci), CoffeeScript est déjà 11ème, en passe de dépasser Objective-C (le langage de programmation de OSX et iOS). Chaque jour, davantage de bibliothèques (ex. Underscore), frameworks (ex. BatmanJS), modules Node et outils (ex. Pow) passent leur code source en CoffeeScript, en maintienant une distribution JavaScript disponible.

CoffeeScript n’est pas là pour remplacer JavaScript : il est là pour l’améliorer et expérimenter avec des nouvelles syntaxes, approches et fonctionnalités. Il est là pour montrer la voie, et réussit admirablement, comme en témoigne l’inspiration forte que lui reconnaît explicitement ES6 (ES.Next / Harmony : la prochaine version de JavaScript).

En attendant, CoffeeScript produit du JavaScript compatible avec tous les navigateurs (même IE6, oui oui) et moteurs, à savoir du ES3 / JS 1.5. Au final, c’est juste du JavaScript. Mais plus rapide, plus performant, plus efficace, plus qualitatif que le vôtre. Et quand bien même vous seriez un JavaScripter de génie, faire la même chose en CoffeeScript va plus vite et est plus agréable.

Pour les débutants comme pour les chevronnés

Contrairement à d’autres technologies ou langages « AltJS », CoffeeScript ne cherche pas à vous éloigner de JavaScript. Les concepts-clés de ce dernier, comme le binding, les closures, les prototypes, les règles de portée, etc. ont toujours toute leur place.

CoffeeScript est là pour fournir une manière plus concise, plus lisible, plus performante d’écrire la plupart des idiômes de JavaScript, qu’ils soient simples ou avancés.

Même un développeur JavaScript chevronné court le risque d’un moment d’inattention lorsqu’il réalise un héritage prototypal, manipule le binding explicitement ou copie-colle des composants de tableau ; il pestera tout autant qu’un débutant devant la quantité de code (et donc de source potentielle de bugs) nécessaire au resting/spreading d’arguments, à une itération filtrée, ou même à une simple boucle numérique.

Ce n’est pas par hasard qu’on trouve parmi les défendeurs de CoffeeScript des grands noms de JavaScript, à commencer par Brendan Eich lui-même, CTO de Mozilla, inventeur et mainteneur en chef de JavaScript !

JavaScript, sans le bruit

La première chose qu’on remarque quand on se met à CoffeeScript, c’est la réduction du bruit syntaxique.

L’indentation étant significative (comme en Python, HAML, Jade, Makefile et bien d’autres), il n’y a plus besoin d’accolades. En améliorant également le parser (l’analyseur syntaxique), on peut se passer de nombreux délimiteurs et séparateurs, autoriser davantage de syntaxes multi-lignes, et permettre divers petites astuces de confort. En voici quelques-unes :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

# La dernière virgule ne gêne pas : couper-coller facilité !
names = [
  'Élodie',
  'Alexis',
  'Rudy',
]

# Litéraux objets simplifiés
author =
  name: 'Christophe'
  age: 35
  city: 'Paris'

# Expressions de fonctions et interpolation de chaînes
sayHi = (whom) -> "Salut #{whom} !"

JavaScript, sans les pièges

JavaScript a bien quelques verrues, dues à la fenêtre de temps extrêmement courte (10 jours) de sa conception initiale. Parmi celles-ci, on compte notamment les variables globales par défaut, les protocoles de conversion implicite, la perte du binding sur les références de fonction et la copie verbatim de l’API Date de Java.

CoffeeScript prend soin de vous protéger autant que possible de ces écueils.

Par exemple, toutes les variables employées sont automatiquement locales (déclarées var), sauf à ce qu’elles figurent aussi sur une portée englobante, auquel cas on suppose une identité (pas de masquage local). Puisque tout fichier CoffeeScript est traité comme un module (englobé dans un module pattern), la pollution de l’espace de noms global ne peut plus être qu’intentionnelle (et honteuse).

Les comparaisons laxistes == et != sont traduites en versions strictes === et !== en JavaScript ; d’ailleurs, les opérateurs == et != sont découragés au profit de is et isnt, plus lisibles et moins porteurs d’une mauvaise interprétation. La conversion de type se doit donc d’être explicite, ce qui est une bonne pratique.

La boucle for…in étant utilisée sur des tableaux (à tort) par tous les débutants JS, en particuliers ceux habitués à PHP, CoffeeScript en fait une vraie boucle (numérique) sur tableaux et utilise for…of pour itérer sur les propriétés d’un objet.

Il est possible de forcer le binding d’une méthode, ou d’une fonction anonyme de callback, rien qu’en remplaçant la flèche simple -> par une double => (fat arrow).

Et j’en passe…

JavaScript, plus qualitatif et plus performant

L’étude du code JS généré par CoffeeScript est riche d’enseignements. L’opération étant volontairement transparente (elle prend soin de faciliter la mise en correspondance mentale entre code CoffeeScript et code JavaScript), on peut y repérer une grande quantité de bonnes pratiques et d’optimisations qui font tristement défaut à la grande majorité des codes écrits manuellement.

Du hoisting explicite des variables à l’optimisation des boucles sur tableaux en passant par le recours systématique et optimal à slice et splice, il est rapidement manifeste que le code généré par CoffeeScript est plus qualitatif et dans l’ensemble plus performant que celui écrit à la main, même par un expert. De la même façon, finalement, que le code produit par un compilateur surclassera généralement le code assembleur écrit à la main par un humain (et le code de plus haut niveau aura pris une fraction du temps à écrire).

Des syntaxes complémentaires super utiles

CoffeeScript regorge de syntaxes concises, le plus souvent très lisibles (plus lisibles que leur équivalent JavaScript, en tout cas, surtout pour un néophyte) et porteuses d’une richesse fonctionnelle délicieuse. Voici quelques exemples :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56

# Modificateurs de fin de ligne : if/unless/while/until
runCallbacks() if callbacksEnabled unless mode is 'silent'

# Opérateur existentiel : vérifie d'abord que client n'est ni null ni undefined
client.sendPacket bundle if client?.open

# - Rest + spread sur les arguments supplémentaires à event
# - Compréhension de tableaux
trigger = (event, args...) =>
  observer.notify args... for observer in @observers[event]

# - Arguments par défaut
# - L'absence d'accolades autour de l'objet d'options donne
#   l'impression d'avoir des paramètres nommés :-)
fadeIn = (speed = 'fast') => @animate opacity: 1, speed: speed

# Compréhension de tableau conditionnelle
foods = ['broccoli', 'spinach', 'chocolate']
eat food for food in foods when food isnt 'chocolate'

# Tableau par intervalle (descendant !)
countdown = [10..1]

# Boucle dédiée for…of (équivalent étendu du for…in de JS)
console.log "#{prop} is #{value}" for prop, value of author

# Slicing de tableau
centerNames = names[2..4]

# true peut se dire aussi on ou yes, selon ce qu'on trouve naturel
launch() if ignition is on

# Comparaisons chaînées FTW!
inTheNorm = 80 < index < 120

# La POO classique devient super simple
class Geek extends Person
  constructor: (@name, @language = 'js') ->
    super @name

  code: -> console.log "Hacking away in #{@language}!"

# Affectation destructurée simple : inversion de variables
[a, b] = [b, a]

# Les regexes deviennent plus faciles à documenter/relire,
# grâce à une syntaxe de bloc.
OPERATOR = /// ^ (
  ?: [-=]>             # function
   | [-+*/%<>&|^!?=]=  # compound assign / compare
   | >>>=?             # zero-fill right shift
   | ([-+:])\1         # doubles
   | ([&|<>])\2=?      # logic / shift
   | \?\.              # soak access
   | \.{2,3}           # range or splat
) ///

Vous trouverez le détail des syntaxes étendues sur la page officielle. Ça fait rêver !

Un workflow non pas ralenti, mais accéléré

Ce n’est pas parce qu’on utilise un langage de plus haut niveau qu’on doit se taper la conversion manuellement avant chaque test. Tout comme LESS, SASS ou Stylus pour les CSS, CoffeeScript propose un watcher qui surveille vos sources pour produire les versions JS correspondantes dès que les fichiers d’origine changent.

C’est naturellement combinable avec les principaux outils de traitement automatique (notamment l’enrobage en modules, la concaténation et le compactage) tels que Brunch, Yeoman, Grunt, CodeKit, Hammer, etc.

Quant au débogage, au-delà de la transparence très raisonnable dans la génération du code JavaScript, CoffeeScript sait produire des source maps qui permettent son débogage natif, par exemple dans Chrome (Developer Channel ou Canary).

Le futur effectif de JavaScript

CoffeeScript n’est pas une bidouille dans un coin, les délires syntaxiques d’un type qui sont voués à l’impasse et à l’oubli. C’est même tout le contraire…

La popularité de CoffeeScript est telle que le TC-39 (groupe de travail au sein de l’ECMA chargé de spécifier les prochaines versions d’ECMAScript, et donc de JavaScript) recourt très régulièrement aux travaux de Jérémy sur CoffeeScript. Ainsi, la syntaxe de classes, les expressions de fonctions comme la fat arrow, les affectations destructurées et d’autres aspects du langage trouvent, petit à petit, leur chemin dans ECMAScript 6, aux côtés d’autres évolutions majeures comme les proxies.

Faire du CoffeeScript ce n’est donc pas s’éloigner de JavaScript, mais bien plutôt s’habituer dès aujourd’hui à ce qu’on trouvera dans le JavaScript de demain !

Formez-vous dès maintenant. C’est le moment !

Cet article ne vous a toujours pas assez donné envie ? Allez donc jouer sur l’excellente page principale du site officiel, avec ses démos exécutables détaillées et sa console « Try CoffeeScript » utilisable à n’importe quel moment.

Ensuite, prenez de l’avance sur la concurrence, valorisez vos compétences et gagnez en valeur ajoutée en assistant dès maintenant à nos formations CoffeeScript. Dotés d’un tarif imbattable et pouvant être prises en charge par vos DIF (comme toutes nos formations), elles sont un véritable cadeau à vous faire.

J’ai passé des années sur Emacs, puis sur Vim, puis sur TextMate. Étant un développeur web sur OSX faisant beaucoup de Rails, TextMate était un choix évident, avec la pléthore d’astuces et d’outils petits et grands pour l’écriture de code Rails que ses paquets renferment… En dépit de ses limitations (pas de split view, fuzzy finder lent à la mise à jour, plus d’évolution significative depuis des années), j’y suis donc resté obstinément, comme beaucoup.

Pendant ce temps, Sublime Text et sa version 2 (« ST2 » dans le reste de cet article) ont acquis petit à petit une renommée significative, au point que je voyais chaque jour davantage de profils similaires au mien qui passaient dessus et ne revenaient pas en arrière. Lorsque je m’y suis mis moi aussi, j’ai pris soin de chercher tout de suite des ressources approfondies sur ST histoire de ne pas le sous-utiliser pendant des mois voire des années, comme le font souvent trop de gens avec un nouvel outil.

Et de fait, ça déchire. Il y a bien sûr quelques petites frustrations de-ci de-là par rapport à TextMate (les snippets et la complétion pour l’univers Rails sont loin derrière ceux de TextMate, malgré des paquets similaires), mais les avantages écrasent les inconvénients. Je suis surtout sensible à sa vitesse (le fuzzy finder est toujours à jour, instantanément, ce qui explose aussi bien celui natif à TextMate que le plugin PeepOpen, qui avait beaucoup de soucis), et l’outil est dispo sur OSX, Linux et Windows, ce qui permet de le standardiser dans une équipe multi-OS. Quant à la possibilité d’étendre soi-même l’outil, elle est similaire à celle de TextMate.

Alors voyons en détail ce que j’adore chez ST, et comment je me le suis configuré.

Un dernier point : je vous encourage fortement à enregistrer votre licence de Sublime Text. Bien sûr il est utilisable à 100% sans paiement (on se prend juste régulièrement une incitation à le payer), mais vu les énormes gains de productivité et de vitesse qu’il permet, je trouve tout-à-fait normal de rétribuer les auteurs. Et après tout, $70 (jusqu’à $50 pour les gros volumes), ce n’est pas cher payé pour un tel avantage.

Pour finir, épargnez-moi les trolls à rallonge dans les commentaires sur la supériorité de tel ou tel éditeur. Je fais toujours beaucoup de Vim, par exemple, notamment via des sessions SSH, et j’aime beaucoup cet éditeur (ST a d’ailleurs un mode Vintage qui lui rend hommage). Il ne s’agit pas ici de dire que l’un est meilleur que l’autre, d’autant que comme souvent, les meilleurs outils sont ceux qu’on maîtrise le plus… Restons sur le sujet, s’il vous plaît.

Pourquoi cet article ?

J’écris cet article parce qu’autant ST peut être extrêmement puissant et confortable, autant son installation par défaut (ST « nu », si vous voulez) n’en laisse pas paraître grand chose… La sidebar est totalement dénuée d’options utiles au clic droit, on n’a pas de transpose, etc. Et même ses fonctions natives puissantes, comme le Go To Anything, la Command Palette ou les Layouts, sont souvent bien peu utilisés, ou sous-employés.

L’idée est donc de mettre en place ici une config « musclée », et de vous fournir également des liens vers des ressources externes de qualité sur ST lui-même, au travers notamment de screencasts, qui constituent toujours une des meilleures approches pour découvrir un éditeur, car l’aspect visuel et animé est important ici. Je peux affirmer que ces ressources m’ont vraiment permis d’avoir rapidement une utilisation efficace de ST, quelques jours à peine après avoir commencé à l’utiliser.

À partir de zéro

Note importante : si vous avez déjà ST d’installé et de personnalisé, il peut être préférable de sauvegarder vos réglages et paquets. Une approche un peu bourrine mais exhaustive consiste à sauvegarder son répertoire Packages entier, qui comprend et les paquets et les configurations par défaut (Default) et utilisateur (User). Vous trouverez ce répertoire facilement en utilisant la commande Preferences: Browse packages de ST (par exemple avec Tools > Command Palette, puis tapez « browse »). Sur OSX par exemple, il s’agit classiquement de ~/Library/Application Support/Sublime Text 2/Packages.

Installation

Vous pouvez télécharger ST depuis son site officiel. L’installation est toute simple, et il ne vous reste plus qu’à le lancer une première fois pour qu’il crée les répertoires de configuration nécessaires.

Structure de la configuration

Deux principes gouvernent la configuration de ST :

1. Il s’agit simplement de fichiers JSON, qu’on édite directement, et qui sont pris en compte immédiatement à la sauvegarde (sauf pour de rares manips, auquel cas c’est précisé par l’auteur du paquet)
2. Il y a trois niveaux de configuration : globale et utilisateur et syntaxe.

Le plus souvent, un paquet fournira les deux premiers niveaux : global et utilisateur. La configuration globale du paquet (ou de ST) fournit généralement le détail des options possibles, parfois commentées, en détaillant leurs valeurs potentielles en commentaires.

L’idée est de ne pas modifier la configuration globale, que ce soit celle de ST ou d’un paquet, mais de surcharger la configuration voulue au niveau utilisateur, en n’y précisant que les réglages modifiés. En effet, lors d’une mise à jour, les fichiers de configuration globaux peuvent parfaitement être remplacés ; si vos personnalisations y figuraient, vous les aurez donc perdues… En les cantonnant à vos fichiers de préférences utilisateur, vous êtes assurés de les conserver.

Certains paquets s’appliquent à plusieurs syntaxes spécifiques et vous permettent alors une configuration par syntaxe. C’est le cas par exemple de SublimeLinter, que nous verrons tout-à-l’heure, qui vous permet à tout instant d’éditer les préférences de linting pour la syntaxe appliquée au fichier actuellement ouvert.

Outre les options de configuration, dont l’extension conventionnelle est .sublime-settings, ST et ses paquets peuvent contenir d’autres éléments : les raccourcis clavier (.sublime-keymap), snippets de code (.sublime-snippet), commandes mises à disposition (.sublime-commands), options de menu (.sublime-menu) et bien d’autres encore. Si le sujet vous intéresse, NetTuts+ a un bon didacticiel (quoiqu’un poil ancien) sur le sujet : How to create a Sublime Text 2 plugin.

Killer features

Killer feature #1: navigation ultra-rapide

C’est l’une des principales raisons pour utiliser ST. Naviguer au travers des fichiers, commandes, méthodes, etc. est extrêmement rapide. Vous retrouverez l’essentiel des commandes possibles, et leurs raccourcis, dans le menu Goto.

Ouvrir un fichier

La commande générique Go To Anything est accessible via Cmd+P sur Mac (Ctrl+P sur Linux/Windows). Elle ouvre un fuzzy finder systématiquement à jour (si vous avez de nouveaux fichiers qui viennent de débarquer dans votre arborescence, par exemple), il ne reste donc plus qu’à taper des fragments significatifs du chemin/nom du fichier (la correspondance n’est pas uniquement sur le nom de base, mais sur le chemin, et l’ordre est important). Inutile de taper des espaces entre les « fragments ».

Imaginons que vous avez un projet Ruby on Rails sous la main. Vous ouvrez son dossier racine dans ST, ce qui en fait une sorte de projet ad hoc, avec tous les fichiers concernés dans la sidebar. Supposons que vous souhaitiez ouvrir rapidement le modèle Person. Après avoir tapé Cmd+P, si vous tapez simplement pers, vous verrez sans doute plusieurs fichiers : le modèle, le contrôleur, les vues, la migration, les tests, etc. Vous pouvez naturellement recourir aux flèches verticales du clavier pour choisir au sein de cette liste, ou éditer votre saisie pour affiner, par exemle ampers va sans doute restreindre le choix à app/models/person.rb, et il ne vous reste plus qu’à valider.

Ce qui est très sympa, c’est que ST affiche automatiquement le fichier actuellement sélectionné, en mode preview (pas encore d’onglet dédié et persistant), dans l’éditeur. On peut ainsi s’assurer qu’on a bien le fichier voulu sous la main. D’ailleurs, ST fait pareil quand on clique sur un fichier dans la sidebar : il l’affiche en mode preview, et si on clique sur d’autres il remplacera par ceux-ci au fil des clics. Il faut un double-clic pour confirmer l’ouverture et en faire un onglet dédié. Ainsi, on peut chercher un contenu interactivement à travers plusieurs fichiers sans pour autant « pourrir ses onglets ».

À ce sujet, la navigation entre onglets reprend les raccourcis usuels de l’OS ; par exemple, sur OSX, on utilisera comme d’habitude Cmd+Alt+Gauche et Cmd+Alt+Droite (⌘⌥← et ⌘⌥→), de façon circulaire. Les onglets sont par ailleurs numérotés de gauche, à droite, et on peut y accéder directement par Cmd+1, Cmd+2, etc. Je trouve toutefois ça assez peu pratique, car dès que j’ai plusieurs onglets ouverts je ne retrouve pas instantanément leur position, et ça va plus vite de défiler au travers des onglets jusqu’à celui que je souhaite…

Aller à une méthode

Évidemment, tout bon éditeur de code se doit de permettre de naviguer entre les symboles principaux d’un fichier source, et généralement, ce sont des méthodes (dans un fichier Markdown, ce seraient les titres, par exemple). ST ne fait pas exception à la règle et propose Cmd+R pour cela. En fait il s’agit juste du bon vieux Go To Anything où ST a déjà tapé pour vous le symbole @, qui préfixe les recherches dans les symboles du fichier (au lieu du nom du fichier).

Ainsi, si tu es sur ton modèle Person qui a, disons, les méthodes full_name, full_address, authenticate et disable, et que tu fais Cmd+R puis que tu tapes fa, tu vas automatiquement filtrer sur full_address, ça va faire défiler le fichier directement à cet endroit-là (ce qui permet d’être sûr qu’on est bien là où on voulait…), y’a plus qu’à valider avec Entrée. Elle est pas belle la vie ?

Combiner les deux

Ce que beaucoup d’utilisateurs de ST ne percutent pas, et c’est bien dommage, c’est qu’on peut parfaitement combiner la navigation vers un fichier et vers une de ses méthodes, en une seule opération. Il y a là de quoi gagner quelques précieuses secondes, qui à l’échelle de la journée font tout plein de minutes qu’on pourra passer à quelque chose d’un peu plus directement productif que de naviguer dans son code…

Il suffit de faire un Cmd+P, de taper le nécessaire pour filtrer sur le fichier voulu, et de taper manuellement le @ qui passe en mode « interne au fichier », puis le nécessaire au filtrage de méthode. Toujours en prenant mon exemple d’application Rails avec son modèle Person, je pourrais ouvrir directement le fichier modèle sur la méthode full_address en faisant Cmd+P et en tapant quelque chose comme ampers@fa (qui ne correspondra qu’à app/models/person.rb@full_address). Ooooouh que ça va vite, dis donc !

Aller à une ligne précise

Pouvoir aller rapidement à une ligne précise d’un fichier est très utile en développement vu qu’on se prend en permanence des infos sur les lignes : exceptions et erreurs, diffs, etc. On peut bien sûr faire défiler le fichier jusqu’à plus soif, mais ça va plus vite en visant directement la ligne. Chez ST, c’est Ctrl+G qui s’en occupe. Il s’agit là aussi en fait d’un Go To Anything où ST aura rentré pour vous le symbole :, qui préfixe un numéro de ligne. Y’a plus qu’à taper le numéro, ST défile en temps réel pour centrer verticalement l’éditeur sur la ligne visée, il ne reste plus qu’à valider.

Et bien sûr, là aussi tu peux combiner en une navigation l’ouverture d’un fichier et le placement sur une ligne. Si Rails me dit que j’ai un souci ligne 12 dans mon modèle Person, je peux faire Cmd+P et taper ampers:12, paf !

Rechercher une commande

Même s’il y a déjà de nombreuses commandes visibles dans les menus de ST, il y en a encore beaucoup, beaucoup plus qui ne sont pas dotées d’une option de menu. Heureusement, il y a la Command Palette, accessible via Cmd+Shift+P (pour rappel, Shift ou Maj, c’est la majuscule temporaire, hein…). Tu te demandes ce que tu as comme possibilités de formatage ? Tape donc format, tu verras bien (en l’occurrence je n’ai que Format: JavaScript, qui vient du paquet JsFormat, lequel n’est pas là par défaut).

C’est une manière pratique de retrouver le raccourci clavier d’une commande. Du coup, si tu dois retenir un seul raccourci, retiens Cmd+Shift+P : il te permettra de retrouver tous les autres :-) Tu ne sais pas s’il existe un raccourci pour poser un bookmark, ou tu ne te rappelles plus ce que c’est ? Hop, Cmd+Shift+P, bo et tu vois tout de suite que Bookmarks: Toggle est associé Cmd+F2.

Personnellement, je me sers surtout de la Command Palette pour changer de syntaxe sur un fichier dont l’extension n’est pas reconnue (ou pas correctement), ou sur un buffer non sauvegardé dans un fichier. Ainsi, quand je veux montrer un morceau de code JS à la volée en profitant d’un éditeur confortable et d’une coloration syntaxique au poil, je ne reste pas dans la console, j’ouvre un nouvel onglet et je fais Cmd+Shift+P, syjs, Entrée, ce qui active la commande Syntax: JavaScript, et le tour est joué !

Killer feature #2: curseurs multiples

On touche là à l’autre fonctionnalité la plus plebiscitée de ST. Il s’agit d’un mécanisme qui va nous permettre d’éditer plusieurs endroits d’un fichier à la fois ; soit parce qu’on change un fragment identique à plusieurs endroits, soit plus généralement pour appliquer une saisie ou suppression identique à plusieurs endroits (par exemple, afin d’enrober plusieurs lignes par des balises ouvrante et fermante identiques). C’est d’ailleurs la toute première fonctionnalité illustrée sur le site officiel.

Il existe deux grands cas de figure.

Remplacement local d’un identifiant

Identifiant ou morceau de texte quelconque, s’entend… Il vous suffit de le sélectionner une première fois (idéalement à sa première apparition pertinente, ça évitera du wrapping), après quoi tout dépend de la pertinence des autres occurrences. Si toutes les occurrences dans le fichier sont à manipuler pareil, on peut faire un Quick Find All (Cmd+Ctrl+G), qui les sélectionnera toutes et initialisera un curseur par occurrence. Si seules les quelques occurrences qui suivent sont utiles, on préférera Quick Add Next (Cmd+D), le nombre de fois nécessaire. Si seules certaines occurrences sont utiles, et pas forcément consécutives, on maintiendra Cmd enfoncé en sélectionnant les occurrences voulues (comme toujours, un double-clic sélectionnera automatiquement le « mot » sous le curseur).

Une fois chaque sélection mise en place et dotée d’un curseur, toute saisie effectuée (déplacements, frappe, suppression, etc.), retours chariot compris, sera reflétée sur tous les curseurs. Un renommage massif est donc très simple. Quand on a terminé, on presse Esc.

Saisie à de multiples endroits

Imaginons que vous ayez quelques lignes dans votre texte :

1
2
3
4
5

hello
world
this
is
nice

Vous souhaitez les convertir en un tableau de chaînes JavaScript. Rien de plus simple avec les curseurs multiples :

1. Placez le curseur au début de la première ligne
2. Maintenez Ctrl enfoncé et descendez avec la flèche de curseur jusqu’au début de la dernière ligne
3. Voilà, vous avez 5 curseurs synchronisés
4. Tapez l’apostrophe ouvrante qui sera reflétée pour chaque chaîne
5. Pressez la combinaison de touches, ou la touche, permettant d’aller en fin de ligne (touche Fin ou Cmd+Droite, par exemple) ; tous les curseurs vont en fin de ligne, indépendamment des longueurs de ligne individuelles.
6. Tapez l’apostrophe fermante, puis la virgule, l’espace et enfin soit pressez Suppr soit sélectionnez le retour chariot et supprimez-le, ce qui ramène les lignes en une seule
7. Sélectionnez l’ensemble de la ligne et tapez [ ; si vous êtes dans une syntaxe compatible (dont JavaScript), la sélection sera encadrée par les crochets.
8. Il ne vous reste plus qu’à supprimer la virgule finale dans le tableau (votre curseur doit être juste à côté, déplacez-le une fois pour déselectionner d’abord)

Il est possible de procéder de façon légèrement différente en utilisant le Split Selection Into Lines, ce qui peut sembler plus rapide. En repartant du texte de base, les 6 premières étapes ci-dessus deviennent les 5 ci-dessous :

1. Sélectionnez les cinq lignes
2. Pressez Cmd+Shift+L ; chaque ligne devient une sélection distincte
3. Tapez l’apostrophe : chaque ligne étant une sélection, l’apostrophe encadre chaque sélection
4. Allez en fin de ligne (tous les curseurs suivent)
5. Tapez la virgule puis sélectionnez la fin de ligne (Shift+Droite) et tapez une espace pour les remplacer

À vous de jouer avec les différentes possibilités et de déterminer ce qui vous semble le plus confortable selon la situation et la manipulation à effectuer.

Killer feature #3: layouts & focus groups

Lorsqu’on vient d’éditeurs comme Emacs ou Vim, disposer de plusieurs vues simultanées, qu’il s’agisse de fichiers distincts ou de plusieurs portions du même fichier, est vite indispensable. TextMate n’a pas réussi à nous donner ça (pas assez vite en tout cas), et ST fournit une gestion potable, même si elle ne permet pes des layouts très avancés (on a des plugins qui font ça, ceci dit ; les fans du split de Vim trouveront sans doute leur bonheur avec Origami, par exemple).

Le principe de base est le layout. ST propose, via son menu View > Layout, 7 possibilités :

• Une seule vue (mode par défaut)
• Layout horizontal à 2, 3 et 4 colonnes
• Layout vertical à 2 ou 3 lignes
• Layout grille en 2 × 2

Les raccourcis clavier ont tous une base Cmd+Alt+num (1, 2, 3, 4 et pour la grille 5), avec Shift en plus (et 2 ou 3) pour les layouts verticaux. Évidemment, sur un laptop au clavier français, les raccourcis à base de Shift+num ne marcheront pas, le Shift étant déjà nécessaire pour accéder aux nombres…

Chaque panneau du layout est ce qu’on appelle un focus group. Il est alors possible de placer les onglets dans le focus group de son choix, soit par simple glisser-déplacer, soit en activant l’onglet et en utilisant le raccourci qui va bien (Ctrl+Shift+num). On peut également changer le focus group actif au clavier (Ctrl+num). Lorsqu’on réduit le nombre de focus groups, les onglets présents dans ceux qui dégagent se voient agrégés aux groupes restants. Lors de l’ouverture d’un onglet, celui-ci apparaît dans le groupe qui était actif à ce moment-là.

Pour voir deux morceaux d’un fichier en parallèle, il suffit d’ouvrir à nouveau le fichier dans un autre groupe. Les deux vues sont synchronisées en termes de contenu : ce que vous tapez dans l’un est retranscrit directement dans l’autre.

Et tellement, tellement plus…

Sans même aller chercher des paquets en plus, ST a des tas de petits détails appréciables. Sa gestion du rechercher-remplacer, par exemple, au sein d’un fichier comme au global (basée sur Ack), est excellente. Ainsi, il affiche en temps réel les correspondances lors de l’élaboration d’une recherche par expression rationnelle, ce qui permet d’éviter d’y aller à l’aveugle. Il est possible de pré-remplir les champs de recherche et remplacement depuis l’éditeur lui-même, afin de gagner du temps. Plein de petites choses sympa comme ça.

Réglages de l’indentation

Quand on parle d’indentation, c’est tout de suite chacun son style… Le seul sujet où tout le monde est à peu près d’accord, c’est : « oui, indenter correctement c’est une bonne chose ». Ce qui est amusant, c’est que ça n’empêche pas une bonne partie de gens d’avoir des boutons à l’idée que leur langage exige une indentation correcte (Python, CoffeeScript, HAML, Jade, etc.) :-)

En tous les cas, lorsqu’il s’agit de l’indentation et de la gestion des espacements d’une manière générale, ST propose plusieurs fonctionnalités et réglages, ainsi qu’un menu déroulant dédié à l’indentation en bas à droite de la fenêtre, juste avant le choix de syntaxe :

Réglages automatiques en fonction du contenu du fichier

Le réglage detect_indentation, qui est à true par défaut, fait qu’à chaque ouverture de fichier, ST va tenter de détecter les réglages d’indentation à appliquer. L’idée est de faciliter le respect du style en vigueur dans le fichier. Le type de caractère employé ainsi que la taille de l’indentation seront automatiquement ajustés. Si vous avez recalé ce réglage à false, vous pouvez néanmoins exécuter cette détection manuellement pour le fichier en cours en choisissant Guess Settings From Buffer dans le menu d’indentation de la barre d’état.

Réglages par syntaxe

L’exécution de l’indentation exploite plusieurs réglages :

• Le type de caractère employé : tabulation ou espaces. Le réglage correspondant s’appelle translate_tabs_to_spaces : s’il vaut true, on utilise des espaces, sinon des tabulations.
• La taille de l’indentation, en caractères affichés. On peut mettre ce qu’on veut mais les réglages les plus fréquents sont 2 et 4. C’est le rôle du réglage tab_size.
• Le comportement en cas de retour arrière (BackSpace). Quand le réglage use_tab_stops est à true, le retour arrière ramène au dernier taquet d’indentation (d’après tab_size).
• L’indentation automatique. Nous la couvrirons dans un instant.

Ces réglages sont définis, par défaut, pour chaque syntaxe. Lorsque vous les changez interactivement via la partie inférieure droite de la barre d’état (juste à gauche du sélecteur de syntaxe), ces réglages persistent pour la syntaxe en vigueur, sauf si vous êtes en détection automatique comme vu précédemment. Vous pouvez les modifier au travers de vos réglages par syntaxe (dans le menu Preferences > Settings - More > Syntax-specific - User).

Conversion de l’indentation

Si votre fichier utilise un autre caractère d’indentation, ou (plus souvent) un mix embarassant d’espaces et de tabulations, vous pouvez recaler vers le caractère voulu au moyen des deux options du menu d’indentation Convert Indentation to Spaces et Convert Indentation to Tabs. Toutefois, cela ne renormalise pas l’indentation structurelle : il vous faudra pour cela un paquet de formatage dédié à votre syntaxe. Pour JavaScript, j’utilise comme nous le verrons plus tard JsFormat.

Indentation automatique

Sans nécessiter de paquet complémentaire, ST est tout de même capable d’observer certaines règles d’indentation automatique, c’est-à-dire de définition de l’indentation à employer lorsque vous créez une nouvelle ligne (en général en pressant Entrée). Les réglages concernés sont :

• L’activation de l’indentation automatique : auto_indent (qui est à true par défaut).
• Les améliorations standard à cette indentation automatique : smart_indent (également active par défaut). Détecte que vous venez d’entrer dans un bloc, par exemple, et augmente tout seul le niveau d’indentation.
• L’alignement des paramètres sur plusieurs lignes : indent_to_bracket. Heureusement désactivé par défaut (je déteste ça), ce réglage insère automatiquement l’indentation variable nécessaire si, au sein d’une déclaration de fonction par exemple, vous allez à la ligne au milieu de la liste de paramètres et voulez que la nouvelle ligne démarre alignée avec le premier paramètre de la précédente :

1
2

function uglyFormat(message, targets,
                    options)

Comme diraient nos amis anglophones : « what the— I don’t even— ?! ». Mais bon, les goûts et les couleurs, hein…

Espaces de fin de ligne et de fin de fichiers

Il ne s’agit pas à proprement parler d’indentation mais on retrouve souvent ces réglages documentés/discutés au sein de l’indentation en ce qui concerne ST. Trois réglages gèrent ces espaces :

• trim_automatic_white_space s’assure que lorsque le curseur quitte une ligne où ST a inséré automatiquement une indentation derrière laquelle il n’y a finalement rien, cette indentation automatique est dégagée pour ne pas laisser d’espace de fin de ligne qui n’aurait pas été ajouté explicitement par l’utilisateur. C’est actif par défaut.
• trim_trailing_white_space_on_save est à mon sens indispensable : activé, ce réglage s’assure à la sauvegarde du buffer que tout espacement de fin de ligne est dégagé. Mais comment vit-on sans ?!
• ensure_newline_at_eof_on_save est un petit réglage bien utile qui s’assure à la sauvegarde que le fichier se termine par une ligne vide. On s’est tous pris des diffs pourris par un « No newline at end of file » sous prétexte qu’on a changé la fin du fichier, qu’il avait une ligne vide avant et plus maintenant, ou inversement. Ce réglage normalise ça automatiquement (autre bonus : un cat sur le fichier ramènera toujours le prompt en début de ligne ;-)).

Package Control et paquets recommandés

Déjà, premier truc à faire, s’assurer qu’on a installé Package Control. C’est une sorte de gestionnaire de paquets pour ST. Il ne connaît pas tous les paquets possibles (n’importe qui peut coller un paquet quelque part sur le web, on n’a pas besoin de notifier Package Control), mais pour ceux qu’il connaît, il est nettement plus pratique que de chercher le paquet en ligne et l’installer à la main…

L’installation de Package Control est l’une des rares manips qui nécessitera le redémarrage de ST, ainsi que l’utilisation de la console de ST.

1. Ouvrez la console de ST. Le raccourci clavier ne marche pas dans tous les environnements, je vous invite donc à juste aller dans le menu View > Show Console.
2. Ça affiche une zone claire en bas de la fenêtre, prête à la saisie. Copiez-collez le code Python indiqué sur la page d’installation et validez
3. La console va bosser quelques secondes et vous afficher au final « Please restart Sublime Text to finish installation ». Redémarrez ST.

À présent, vous avez accès à l’installation et la gestion des paquets via Package Control juste en lançant la Command Palette (Cmd+Shift+P ou Ctrl+Shift+P) et en tapant « Package ». Vous verrez toute une liste de commandes pour installer, désinstaller, mettre à jour, activer, désactiver, lister des paquets, et j’en passe. Les commandes affichent leur déroulement dans la barre d’état, sur la gauche.

Mes paquets supplémentaires chéris

Voici ma liste de paquets Sublime Text recommandés, par ordre alphabétique.

AdvancedNewFile (détails)

Permet de créer un fichier au clavier depuis n’importe où, au moyen du raccourci clavier associé (par défaut Cmd+Alt+N ou Ctrl+Alt+N). Dans la zone de saisie qui apparaît en bas de la fenêtre, on peut alors taper le chemin qu’on veut (si on est dans un projet ou pseudo-projet, la racine implicite est celle de celui-ci), la complétion étant disponible. Si on tape des noms de dossier inexistants, ils seront créés à la volée.

Je m’en sers pour aller plus vite qu’en reprenant la souris / le trackpad pour dérouler mes divers niveaux de dossier et enfin faire clic droit + New File.

Voici un court screencast qui illustre bien AdvancedNewFile

Alignment (détails)

Permet d’homogénéiser l’indentation de plusieurs lignes ou sélections (eh oui, souvenez-vous, on a les curseurs multiples !) mais je m’en sers principalement pour aligner les = de plusieurs lignes adjacentes (et donc, au passage, les => de Ruby). Il suffit de sélectionner les lignes en question et de presser Cmd+Ctrl+A (OSX) ou Ctrl+Alt+A (autres). Ça transforme par exemple le foutoir suivant :

1
2
3

name = @customer.full_name
  capacity    = @customer.plan.quota
addressee = capacity > 0 ? name : @customer.plan.admin.full_name

…en ceci (en deux temps : la première fois, ça homogénéise l’indentation, la seconde ça aligne les =) :

1
2
3

name      = @customer.full_name
capacity  = @customer.plan.quota
addressee = capacity > 0 ? name : @customer.plan.admin.full_name

CoffeeScript (details)

Prise en charge complète de CoffeeScript, le petit langage qui tue par-dessus JavaScript. Outre que j’en fais tout le temps, il est bien pratique lors de la formation, puisqu’il propose entre autres un mode Watch qui maintient en temps réel le résultat du transpiling vers JS dans un buffer. En combinant avec la vue horizontale à deux panneaux, j’ai donc du live transpiling cash dans mon éditeur, ce qui est top :-)

Emmet (détails) — indispensable !

Emmet est en quelque sorte le successeur de Zen Coding. Il fournit de très nombreuses aides à la saisie pour HTML et CSS, en proposant d’une part des syntaxes ultra-courtes pour générer une tonne de code souhaité, et d’autre part de nombreuses actions de manipulation du code existant. Une fois qu’on s’y est mis, on ne revient pas en arrière…

Pour vous en convaincre, jetez donc un œil à la vidéo et aux docs.

Gitconfig (détails)

Coloration syntaxique pas trop naze pour mes fichiers de configuration Git (~/.gitconfig et .git/config), parce que d’abord.

Ce paquet n’est pas connu de Package Control. Le plus simple pour l’installer est d’ouvrir une ligne de commande dans le répertoire de paquets de ST (accessible notamment en faisant Settings > Browse packages), et d’y décompresser le Zip du paquet ou d’y clôner son dépôt Git. Le paquet est pris en charge automatiquement par ST.

Vous pouvez donc :

• Clôner le dépôt si vous utilisez déjà Git
• Récupérer le Zip et le décompresser dans le cas contraire ; la page de dépôt Github propose à gauche des URLs de clonage un bouton “Zip” bien en évidence, qui vous fournit l’archive correspondante.

GitGutter (détails)

Affiche dans la goutière (la barre verticale à gauche du texte qui contient les numéros de lignes, marqueurs de bookmarks, etc.) des marqueurs de modification Git (insertions, modifications, suppressions). Ce n’est pas indispensable, mais lorsque je suis en train de bosser sur un commit long, de résoudre un conflit ou d’examiner un diff, ça me permet de tout de suite voir les lignes concernées, ou de remarquer que des lignes ont l’air d’avoir bougé alors qu’elles n’auraient pas dû, etc.

Haml (détails)

Prise en charge complète de Haml, un langage de templating que j’utilise systématiquement sur mes projets Rails. Fournit la coloration syntaxique, les snippets et tab triggers, les raccourcis claviers, etc.

Handlebars (details)

Coloration syntaxique pour le langage de templating Handlebars, que j’utilise beaucoup en formation (JS Guru et JS Total). Bonne qualité de coloration et de contraste plus tab triggers (morceaux dynamiques de code déclenchables par tabulation) pour les blocs les plus courants.

Jade (détails)

Coloration syntaxique pour Jade, un langage de templating côté client (orienté environnements JavaScript, quoi) très similaire à HAML, que j’utilise de préférence à Handlebars.

JsFormat (détails)

Il s’agit d’une sorte de surcouche par-dessus l’excellent JS Beautifier, qui permet de reformater du JS en se conformant à un certain nombre de réglages qui définissent un coding style. Calé sur un raccourci-clavier (Ctrl+Alt+F par défaut), il est notamment très pratique pour formatter vite fait une grappe JSON renvoyée par une API ou « déminifier » un code récupéré sur un site en production.

LoremIpsum (détails)

On a tous besoin d’un générateur de texte aléatoire dans nos éditeurs, surtout ceux qui font du développement web front… Ce petit paquet remplit bien son office, avec une insertion calée sur Cmd+Alt+L, qu’on peut répéter autant de fois qu’on veut pour avoir des textes supplémentaires (qui démarrent toutefois tous par « Lorem ipsum »). On a également un tab trigger basé sur « lorem ». Des réglages permettent de définir la taille des fragments insérés (un peu, pas mal, beaucoup…), et des commandes dédiées par taille sont également accessibles dans la Command Palette.

Sass (détails)

Une bonne partie de mes CSS sont en SASS (plus exactement en syntaxe SCSS), j’ai donc besoin d’une coloration syntaxique valable et, idéalement, d’une aide à la saisie (le paquet fournit une saisie des propriétés basée sur les raccourcis Zen Coding).

SideBarEnhancements (détails) — indispensable !

Je sais pas comment je vivrais sans celui-là. Le menu contextuel de la sidebar dans ST « nu » est consternant : on ne peut pratiquement rien faire. Grâce à ce paquet, on a une tonne de commandes super pratiques, souvent associées à des raccourcis clavier.

Open with, Rename, Move, etc. mais aussi les nombreuses options de Copy as Text, Duplicate, Open in Browser (raccourcis super simples, idéal pour ouvrir immédiatement le document HTML/SVG dans un navigateur), Find Advanced… Une vraie mine d’or pour des manips qu’on fait d’ordinaire à la main au moyen d’une ligne de commande parfois complexe.

SmartMarkdown (détails)

La prise en charge de Markdown par ST est très, très light. On a une partie de la coloration syntaxique, et c’est tout. Je n’ai pas encore trouvé une super coloration et une bonne gestion de raccourcis-clavier pour le gras, l’italique, le code, les liens, etc. mais au moins avec ce paquet j’ai des aides structurelles vraiment sympa : folding pas mal foutu sur les niveaux de titre, continuation automatique des listes (ordonnées ou non), navigation par titre, gestion des tableaux en convention Pandoc, etc.

Stylus (détails)

Je fais de plus en plus de CSS en Stylus plutôt qu’en SASS, pour la même raison que je fais du Jade : de moins en moins de bruit syntaxique, de plus en plus d’expressivité. Il me faut évidemment une coloration syntaxique à la hauteur (capable de s’y retrouver avec beaucoup moins de « marqueurs » que d’habitude) et, idéalement, un accès direct au transpiling vers CSS.

Ce paquet a quelques dépendances externes (sur OSX, il lui faut le « binaire » stylus obtensible par installation globale du paquet npm homonyme), mais c’est bien normal vu que la complexité d’analyse syntaxique est suffisante pour préférer déléguer celle-ci au transpiler d’origine au lieu d’essayer de se la farcir au sein de ST…

SublimeLinter (détails) — indispensable !

Attention tuerie ! La pratique du linting s’est bien répandue depuis JSLint et JSHint, mais elle est en fait possible sur la majorité des syntaxes. Au minimum, la plupart des compilateurs et interpréteurs vous permettent de juste indiquer des erreurs syntaxiques dans leur langage. Au mieux, vous disposez d’outils d’analyse statique de code capables de détecter des code smells tels qu’une variable inutilisée, un fragment de code jamais exécuté, une syntaxe connue comme problématique sur les vieux IE, un sélecteur CSS trop long ou verbeux pour être honnête…

Ce paquet fournit un mécanisme universel de linting qui recourt ensuite aux outils appropriés en fonction de la syntaxe du buffer en cours. Je l’utilise notamment pour Ruby, JavaScript, CoffeeScript et CSS. Il est vraiment très pratique.

Le linting peut être fait en direct (dès qu’un délai d’inactivité, par défaut 2 secondes, a été détecté), automatiquement au chargement et/ou à la sauvegarde, ou manuellement. On peut régler les outils à utiliser en interne (notamment JSLint ou JSHint) et leurs options par défaut. Je vous encourage à utiliser au minimum le mode chargement+sauvegarde, et idéalement le mode « live » (sur délai d’inactivité) : si le linting n’est pas automatique, vous n’aurez pas le réflexe de l’appliquer systématiquement.

TransposeCharacter (détails)

Il est surprenant que ST n’ait pas de base une commande de transposition, au moins des caractères autour du curseur. La dyslexie légère à la frappe, qui résulte de l’inversion de deux caractères, est si fréquente que la majorité des éditeurs ont une telle commande en natif, généralement calée sur Ctrl+T. Même la readline, qui contrôle la saisie interactive dans nombre de shells, le fournit.

À quelque chose malheur est bon toutefois : ce paquet va plus loin que la simple transposition de caractères. Si le curseur est en début ou fin de ligne, il inverse la ligne courante et la précédente/suivante. En théorie, si une sélection est active, il inverse le côté de la sélection où se trouve le curseur. Toutefois pour moi, même si ça marche en invocation de commande explicite (Cmd+Shift+P, transpose), ça ne donne rien avec le raccourci clavier…

Unicode Character Highlighter (détails)

Ce paquet permet de mettre automatiquement en lumière (les couleurs sont réglables en triturant le code, ahem…) un certain nombre de caractères Unicode au sein du buffer, par exemple les guillemets français. Mais ce qui m’intéresse particulièrement, moi, c’est qu’il met en exergue les espaces insécables littérales (oui, en typographie, on dit une* espace).

Je suis en effet sur un clavier Mac ou je tape régulièrement et volontairement de telles espaces (Alt+Espace), car j’aime avoir le strict minimum d’entités HTML dans mes documents à destination du web (et je ne vous parle pas de tous les cas où je tape un signe double en français dans un contexte qui n’insère pas une telle espace avant automatiquement). Mais il y a des cas où ça arrive sans que je le veuille. Généralement parce que je viens de taper, ou je m’apprête à taper, un caractère reposant aussi sur Alt, à côté d’une espace normale. Et j’enfonce Alt trop tôt, ou je le relâche trop tard.

Prenez par exemple le code Ruby suivant :

1
2
3

customer = current_customer
customer ||= Customer.new
customer.mark_session!

Sur un clavier Mac, pour obtenir un pipe (|), je dois faire Alt+Shift+L. Dans la section de code customer ||= Cus…, il existe un vrai risque à la frappe que je ponde par inadvertance une espace insécable entre customer et ||=, en enfonçant Alt une fraction de seconde trop tôt. L’éditeur ne me le signalera pas, et le code reste valide, ce qui fait qu’à la ligne suivante, la variable customer n’est en fait pas définie, alors qu’apparemment la ligne centrale lui a garanti une valeur ! En réalité cette ligne centrale fournit une valeur à la variable customer  (le dernier caractère de l’identifiant est l’espace insécable).

Je me suis fait mordre par ce type de problème assez de fois pour vouloir voir les espaces insécables immédiatement dans mon code, et bien mises en avant. D’où ce paquet.

Le thème Tomorrow

ST a une gestion assez fine des thèmes, c’est-à-dire des palettes de couleur employées pour afficher les buffers. Tous les thèmes TextMate sont naturellement exploitables, et pendant longtemps j’utilisais Blackboard pour moi et LAZY pour la vidéo-projection.

Et puis j’ai découvert Tomorrow.

Non seulement il fournit des variantes bien adaptées à mes besoins (j’utilise la variante Night-Bright pour moi et le thème de base pour la vidéo-projection), mais surtout il découpe le code plus finement que la majorité des thèmes ; il différencie davantage de choses. Et l’équilibre colorimétrique est vraiment pas mal. On sent que son créateur, Chris Kempson, est un spécialiste des thèmes et a passé une tonne de temps sur Tomorrow, qui est d’ailleurs immensément populaire. Je l’ai même mis en place au sein de mes slides en RevealJS, pour mes formations JS Attitude (il y a des feuilles de style Tomorrow dans Highlight.js).

Ressources supplémentaires à regarder absolument

On trouve pléthore d’articles et séries d’astuces sur le web autour de ST. La plupart se répètent… Mais voici deux ressources que je trouve indispensables :

• L’excellent screencast gratuit chez NetTuts+ : Perfect Workflow in Sublime Text 2. Bien structuré et découpé pour un accès ciblé facile, plus de 3h de screencast qualitatif, avec une tonne métrique de manips utiles pour être bien opérationnels tout de suite !
• Le screencast de Mike Riley téléchargeable chez Pragmatic Programmers : Sublime Text 2. 54 minutes, seulement $12, dispo en une pléthore de formats.

Allez à présent, et éditez dans la joie !

• JS Total du 9 au 12/04 (attention, il ne reste presque plus de places)
• CoffeeScript le 23/04. Jetez-vous dessus, ça déchire !
• JS Puissant le 30/04
• JS Guru le 21/05
• CoffeeScript le 19/06
• JS Total du 25 au 28/06

Comme toujours, vous pouvez demander une convention pour une session inter-entreprises (remplissez bien tous les champs), ou nous contacter pour un besoin intra-entreprise ou sur mesure.

Pour rappel, les sessions suivantes arrivent :

• 9–12 avril : c’est la prochaine JS Total, et comme d’habitude elle est déjà presque pleine un mois à l’avance. C’est notre blockbuster et ça n’a rien d’étonnant, vu son programme alléchant. Dépêchez-vous de rafler les dernières places libres, sinon vous devrez attendre juin !
• 23 avril verra la première session CoffeeScript, attendue de longue date, qui va mettre elle aussi des étoiles plein les yeux des participants…

Côté Git, la session Git au Quotidien du 26 mars est déjà pleine, mais il reste des places pour l’excellente Git Avancé qui suivra le 27 mars.

Nous annoncerons d’ici une à deux semaines les dates des sessions inter-entreprises pour mai (il y en aura peu, le mois est déjà chargé pour nous) et juin 2013.

Voici donc dix bonnes pratiques choisies parmi un large ensemble de candidates ; vous en connaîtrez sûrement certaines, mais probablement pas toutes. Je pensais qu’il en faudrait 10 pour faire un article un peu consistant, et au final c’est un mammouth qui aurait pu être découpé en plusieurs articles histoire de faire durer le plaisir… Mais je suis d’humeur généreuse et j’ai encore plein d’articles sous le coude, alors je vous livre tout ça d’un coup :-)

N’hésitez pas à faire vos retours en commentaires !

1. Court-circuiter les blocs plutôt que les imbriquer

Court-circuiter le code, en JavaScript, c’est recourir à return, break ou continue pour sauter tout ou partie du contexte en cours (fonction ou boucle), et s’épargner ainsi des blocs imbriqués inutiles, avec ce que ça suppose d’indentation supplémentaire…

Il est certes primordial de bien indenter son code, quel que soit le langage. Dès qu’on ne se limite pas à un code trivial de 2-3 lignes, visualiser les dépendances logiques des conditions, boucles et fonctions devient impératif.

Toutefois, il est dommage d’indenter inutilement. Trop d’indentations imbriquées crée souvent un a priori négatif sur le code en donnant une vision faussée de sa complexité. Cela rend aussi le code moins lisible et facile à appréhender.

Voyons quelques exemples.

1
2
3
4
5
6
7
8
9
10
11
12

function processItems(list) {
  var result = [];

  if (items.length > 0) {
    normalize(items);
    for (var index = 0, len = items.length; index < len; ++index) {
      // code bien long…
    }
  }

  return result;
}

Ici il est dommage d’avoir deux niveaux. Le cœur de code étant dans un if, il suffit de tester la condition inverse et de court-circuiter avec un return :

1
2
3
4
5
6
7
8
9
10
11
12
13

function processItems(list) {
  var result = [];

  if (items.length <= 0)
    return result;

  normalize(items);
  for (var index = 0, len = items.length; index < len; ++index) {
    // code bien long…
  }

  return result;
}

Le même principe peut s’appliquer dans les boucles, en utilisant suivant les cas continue ou break. Ainsi, le code suivant :

1
2
3
4
5
6
7

while (items.length > 0) {
  var item = items.pop();

  if (item.hasOwnProperty('taggable')) {
    // code bien long…
  }
}

…deviendrait celui-ci :

1
2
3
4
5
6
7
8

while (items.length > 0) {
  var item = items.pop();

  if (!item.hasOwnProperty('taggable'))
    continue;

  // code bien long…
}

Au passage, vous ne le savez peut-être pas mais break et continue autorisent le recours à un label pour court-circuiter au-delà de leur boucle conteneur immédiate, et remonter ainsi de plusieurs niveaux (mais toujours au sein de la fonction courante). Voici un exemple de recherche dans une matrice, hors la diagonale. On ignore la diagonale en court-circuitant le tour courant avec un continue simple, mais si on trouve la valeur recherchée, on court-circuite l’ensemble des boucles pour aller directement à la suite de la fonction, au moyen d’un label sur la boucle externe et de son emploi dans le break interne :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

function searchGridExceptDiagonal(grid, cell) {
  var result;

  outer: for (var rowIndex = 0, rows = grid.length; rowIndex < rows; ++rowIndex) {
    for (var colIndex = 0, cols = grid[colIndex].length; colIndex < cols; ++colIndex) {
      console.log(rowIndex, colIndex);

      if (rowIndex == colIndex)
        continue;

      if (cell === grid[rowIndex][colIndex]) {
        result = [rowIndex, colIndex];
        break outer;
      }
    }
  }

  return processResult(result);
}

Enfin, il existe le fameux cas du « return else », un cas classique de superflu. Voyez plutôt :

1
2
3
4
5
6
7
8
9

function processItems(items) {
  if (items.length <= 0) {
    return [];
  } else {
    var result = [];
    // code bien long…
    return result;
  }
}

C’est parfaitement superflu, comme en atteste l’exemple plus haut : un return court-circuite la fonction conteneur, le else est donc sans intérêt : on peut utiliser directement le code qu’il contient.

Bref : l’indentation c’est bien, mais en faire trop c’est moins bien ! N’abusons pas des bonnes choses…

2. Comparer avec les rvalues à gauche

Qu’est-ce qu’une rvalue ? En jargon d’analyse syntaxique (parsing), on désigne ainsi l’opérande droit d’un opérateur. Par symétrie, l’opérande gauche est appelé lvalue. Par exemple, dans x == 42, x est la lvalue et 42 la rvalue. Dans str += 3, ce seraient évidemment str et 3, respectivement.

Dans tous les langages où l’opérateur d’affectation (=) est un sous-ensemble de celui de comparaison (==), et où l’affectation est une expression, on risque de tomber dans le piège du égale manquant. Ainsi en JavaScript C, C++, Java, Ruby, etc. on peut se gaufrer comme suit :

1
2
3
4

for (var index = 0, len = list.length; index < len; ++index)
  if (list[index] = 42) {
    // code de traitement…
  }

Vous avez vu la blague ? Le = au lieu du == ? C’est un piège fréquent même pour les développeurs chevronnés : après tout, c’est « juste » une faute de frappe. Mais c’est tellement discret que ça peut être infernal à déboguer.

Si vous avez un bon outillage associé à votre éditeur de code, votre compilateur ou votre interpréteur, il vous fera probablement remarquer qu’il y a ici baleine sous gravier. C’est par exemple le cas de JSLint et JSHint, tous deux fournis par exemple dans Sublime Text 2 au moyen de l’excellent plugin SublimeLinter.

Vous avez alors le choix :

• soit il s’agit bien d’une affectation à la volée (pour utilisation de la valeur dans le bloc, par exemple), et vous pouvez rendre ça explicite en doublant les parenthèses ;
• soit c’est une comparaison et vous rajoutez un =.

Toutefois, le souci principal c’est que ça puisse arriver (ce code s’exécute, il est valide ; il fait juste n’importe quoi…) alors que vous visiez une comparaison. C’est pourquoi dans tous ces langages j’ai le réflexe d’inverser, pour les comparaisons d’égalité uniquement (== et ===, en JavaScript), la lvalue et la rvalue. Ça donnerait ceci :

1
2
3
4

for (var index = 0, len = list.length; index < len; ++index)
  if (42 == list[index]) {
    // code de traitement…
  }

Voyez-vous ce qui se passe ? Si j’oublie un =, l’affectation résultante n’est pas valide : je ne peux pas modifier le litéral de gauche… Bien sûr, si je compare deux variables ou autres opérandes modifiables, ça ne m’aide pas. Et si j’opte normalement pour des égalités strictes (===), le risque de n’avoir qu’un = est bien moindre. Mais au global, c’est une habitude qui a sauvé un nombre incalculable de fois mes étudiants, stagiaires, collègues… et moi-même, naturellement.

3. Mettre en cache les expressions lourdes

Il existe de nombreux cas où une expression JS, aussi courte soit-elle, est lourde à exécuter.

Certaines sont intuitivement lourdes, comme le $(selector) de jQuery (ce qui n’empêche pas les gens de faire quinze fois la même sélection dans leur fonction…) ou un appel à une de vos fonctions dont vous savez qu’elle mouline pas mal.

D’autres sont plus subtiles ou surprenantes, comme les litéraux d’expressions rationnelles ou les longueurs de tableaux.

Mettre en cache, ou si vous préférez memoizing ces expressions peut avoir une influence notable sur vos performances dans un code utilisé intensivement.

Commençons par les cas évidents :

1
2
3
4
5
6
7

// BEUARK :
$('#foo .bar').on('click', handleBarClick);
if (escapesToo)
  $('#foo .bar').on('keypress', handleEscapes);
items.forEach(function(item) {
  $('#foo .bar').append(item);
});

Ce type de code est plus fréquent qu’on ne croie, tant les développeurs préfèrent copier-coller que refactoriser leur code, aussi simple cela soit-il ici. Naturellement, conserver l’objet jQuery résultat est une bien meilleure option (ou recourir au chaînage, quand c’est possible) :

1
2
3
4
5
6
7

var scope = $('#foo .bar');
scope.on('click', handleBarClick);
if (escapesToo)
  scope.on('keypress', handleEscapes);
items.forEach(function(item) {
  scope.append(item);
});

Lorsque vous réalisez une fonction dont le résultat n’est pas censé changer pour une même série d’arguments, mais qui est susceptible d’être souvent appelée, il est souhaitable de recourir à la memoization pour cette fonction. Voyons un cas simple, sans arguments :

1
2
3
4
5
6
7
8
9
10
11

function heavyDuty() {
  if (undefined !== heavyDuty.cached)
    return heavyDuty.cached;

  var result;

  // Gros code bien lourd et compliqué, voire coûteux financièrement (appels API, toussa…)
  heavyDuty.cached = result;

  return result;
}

Si ça dépend des arguments, cached peut devenir un hash ({}) dont les clés sont des String construites sur base des arguments. On peut même génériser tout ça facilement et en faire un mixin. La bibliothèque Underscore, parmi ses myriades de fonctions cool, propose ainsi _.memoize à cet effet.

Plus subtil à présent : les expressions rationnelles.

Lorsqu’on recourt à une regex assez courte, il est fréquent de se contenter de la copier-coller, ou simplement de la laisser litérale au sein d’un boucle par exemple. C’est dommage, car alors on risque de la voir « compiler » à chaque utilisation, donc à chaque tour de boucle :

1
2
3
4
5
6
7

// SAYMAL :
for (var index = 0, len = longArray.length; index < len; ++index) {
  var line = longArray[index];

  if (/[\s\u00a0][:;?!]/.test(line))
    return line;
}

Il est préférable de sortir la regex de la boucle, voire de la fonction et d’en faire une « constante » (en ES3, on n’a pas const, on utilisera donc var) :

1
2
3
4
5
6
7
8

var WHITESPACE_AND_DOUBLE_SIGN = /[\s\u00a0][:;?!]/;

for (var index = 0, len = longArray.length; index < len; ++index) {
  var line = longArray[index];

  if (WHITESPACE_AND_DOUBLE_SIGN.test(line))
    return line;
}

Cela a en outre le double avantage d’expliciter le sens de la regex et de faciliter la vie à certaines colorations syntaxiques :-)

Notez au passage une autre bonne pratique conjointe : lorsqu’on veut juste un résultat booléen sur la regex (correspondance ou non), sans s’intéresser au détail de la correspondance, on utilisera avec profit regex.test(string) plutôt que string.match(regex). La première est nettement plus performante que la seconde, car elle renvoie juste un booléen et ne s’occupe pas de constituer des groupes, etc.

Dernier cas évoqué ici : les longueurs de tableaux.

Il est vain de vouloir deviner comment votre runtime JS représente en interne votre Array JavaScript. Cela dépend de la runtime, des types de valeur stockées et de la longueur du tableau. Suivant les cas, il peut s’agir d’un véritable tableau (zone de mémoire continue à indexation directe), d’une liste liée, voire d’une structure plus avancée.

En conséquence, il n’est pas rare (surtout sur les vieux navigateurs) que le code en apparence bénin myArray.length soit en réalité coûteux, exigeant en interne le parcours intégral du tableau. Une boucle « classique » sur la longueur aurait donc une complexité quadratique :

1
2
3

// RISKY
for (var index = 0; index < myArray.length; ++index)
  // …

Dans la mesure où les boucles sur des tableaux dont la longueur change au fil des tours sont rarissimes (et sources de bien des bugs), il est toujours préférable de mettre la longueur (fixe) « en cache » dans une variable, au sein de la section d’initialisation de la boucle :

1
2

for (var index = 0, len = myArray.length; index < len; ++index)
  // …

Naturellement, si vous passez par un itérateur (ceux d’ES5 : forEach, map, some… ou ceux d’Underscore, de jQuery, etc.) vous pouvez leur faire confiance pour avoir fait au mieux.

4. Utiliser la délégation d’événements plutôt que des tas de gestionnaires étroits

On est là aussi dans les trucs rabâchés depuis bien 5 ans, mais je vois toujours plein de gens qui font le contraire, alors revenons-y.

Dans une page web, vous associez des gestionnaires d’événements (event handlers) à des événements sur divers endroits de la page. Le réflexe initial consiste à les associer « au plus près », sur l’élément lui-même en général.

La plupart du temps, ça ne pose aucun souci, c’est même une bonne idée.

Mais il y a au moins deux situations dans lesquelles c’est soit super lourd, soit carrément cassé.

Le premier cas, c’est lorsque vous écoutez le même événement sur pléthore d’éléments. Par exemple, tous les éléments d’une liste ; toutes les lignes d’un corps de tableau ; tous les liens porteurs d’une classe CSS donnée… Attacher un gestionnaire par élément, alors que le comportement est partagé, est inutilement lourd et peut vite dégrader les performances quand le nombre d’éléments est élevé.

1
2
3
4
5

// Un gestionnaire par élément (beuark) :
$('ul#files li').on('click', function(e) {
  var item = $(this);
  // …
});

On préfère alors tirer parti du bubbling (le fait que les événements « bouillonnent » au travers du DOM, d’un élément vers son parent et ainsi de suite jusqu’au document) et attacher le gestionnaire au plus proche commun parent (souvent le document, mais ça peut être bien plus ciblé, comme la liste qui contient tous les éléments souhaités). On aura alors recours à une syntaxe de capture appropriée. Par exemple :

1
2
3
4
5

// Un gestionnaire délégué pour tous les éléments :
$('ul#files').on('click', 'li', function(e) {
  var item = $(this);
  // …
});

(Dans les deux cas avec jQuery, this fera bien référence au <li>.)

L’autre cas de figure où une connexion trop ciblée des gestionnaires d’événement est problématique concerne le chargement/remplacement de contenus HTML (le plus souvent via Ajax). Si on attache ces gestionnaires sur une zone de la page qui va se faire remplacer par la suite (au moyen d’un appel manuel à .html(…) ou $.load(…), par exemple), ces gestionnaires resteront attachés aux anciens éléments désormais disparus, alors que les nouveaux éléments fraîchement injectés ne disposeront pas, eux, de gestionnaires d’événements.

Il est alors préférable de déléguer ces gestionnaires au niveau du conteneur de la zone qui va évoluer (être remplacée/rechargée). jQuery assurant le bouillonnement même des événements qui, sur les vieux IE, ne bouillonnent pas (focus, blur, change et submit), cette solution est exploitable pour tous les événements voulus. Ainsi, nul besoin de les rattacher le moment venu, ou de nettoyer ceux installés avant le remplacement du contenu.

5. Isoler son code avec le module pattern

Encore aujourd’hui, en 2013, l’immense majorité des développeurs JS côté navigateur pondent leur code au niveau global. Imaginons qu’on vous demande de notifier Google Analytics de tout téléchargement de fichier sur votre site, sachant que vous avez pris soin de coller une classe CSS file aux liens correspondants. Vous pourriez ajouter à votre page un script track_downloads.js qui ressemblerait à ceci :

1
2
3
4
5
6
7

function trackLink(link) {
  _gaq.push(['_trackEvent', 'files', 'download', link.href]);
}

$(document).on('click', 'a.file', function() {
  trackLink(this);
});

C’est un cas light, parce qu’en vérité, vos fichiers sont souvent multi-sujets, ou en tout cas « pourrissent le global » avec des tas de fonctions et variables partagées… (Si si, avouez, ça vous arrive, je le sais, je le vois tout le temps).

Outre que ça pose souci le jour où vous utilisez un autre morceau de code qui lui aussi aurait une fonction globale trackLink (collision de noms : le dernier qui a parlé a raison), c’est juste dommage de polluer ainsi la portée globale pour rien. En effet, la majorité de vos codes sont en fait autonomes, ou comme disent les anglais self-contained : ils n’ont pas d’API publique à fournir, ils ont juste du code interne à leur fonctionnement, attaché à la page par gestionnaires d’événements.

Il est dès lors préférable d’enrober votre fichier dans un module. Je ne parle pas forcément d’un « vrai » module (au sens AMD ou CommonJS, par exemple), mais au minimum du module pattern, qui est au cœur des autres et repose simplement sur une fonction immédiatement exécutée (Immediately-Invoked Function Expression, ou IIFE, en anglais) :

1
2
3
4
5
6
7
8
9

(function($, undefined) {
  function trackLink(link) {
    _gaq.push(['_trackEvent', 'files', 'download', link.href]);
  }

  $(document).on('click', 'a.file', function() {
    trackLink(this);
  });
})(jQuery);

Ici tout le code définit en fait une fonction anonyme, qu’il appelle immédiatement. En vertu des règles de portée et de closure de JavaScript, les déclarations de fonction et les var à l’intérieur d’une fonction lui sont privées : l’extérieur ne sait donc rien, par exemple, de trackLink.

J’utilise ici au passage des petites astuces habituelles quant aux arguments de l’IIFE (elle peut très bien ne pas en avoir) :

• Au cas où jQuery serait utilisé en mode noConflict, je me permets tout de même d’y référer facilement avec $ grâce à un argument dédié.
• Si jamais un petit malin a pourri undefined en collant par exemple un undefined = 42; quelque part, ça ne m’atteint pas car grâce à mon deuxième paramètre qui n’aura pas d’argument correspondant, dans mon « module », undefined est bien undefined (bon, ici on ne s’en sert pas, mais c’est un schéma désormais classique…).

Si le sujet des module patterns et toutes les variations/évolutions possibles vous intéressent, cet article déjà ancien de Ben Cherry, développeur front-end chez Twitter, est une excellente lecture.

6. Découpler son code grâce aux événements personnalisés

Le saviez-tu ? Ce n’est pas parce que du code externe a besoin de déclencher du code à toi que tu dois nécessairement en faire une API publique (c’est-à-dire des fonctions accessibles de l’extérieur). En fait, il existe notamment un cas de figure où une fonction publique n’est pas la bonne solution : la maintenance opérationnelle suite à un événement extérieur.

« Gni ? »

Imaginons que tu codes un module qui décore tout champ de type date avec un joli widget à toi (comment ça, tu n’utilises pas Kalendae ?!). Tu as respecté les préceptes du point précédent (module opaque décorant automatiquement les input[type=date], input.date au chargement du DOM, par exemple), mais tu te retrouves soudain confronté à un problème : si quelqu’un met à jour la page plus tard (avec Ajax ou un système de templates…) les nouveaux champs ne seront pas décorés.

Ni une ni deux, tu « exportes » donc une méthode publique, probablement collée en global au niveau de window ou d’un espace de noms dédié à ton module ; une méthode du genre refreshDatePickers(). Peut-être que ton code ressemble à ça, exploitant ce que Ben Cherry appelle la loose augmentation :

1
2
3
4
5
6
7
8
9
10
11
12
13
14

var TotoWidgets = (function(exports) {
  // ton joli code bien planqué ici…

  function refreshDatePickers() {
    // …
  }

  $(function() {
    // ton init ici…
  });

  exports.refreshDatePickers = refreshDatePickers;
  return exports;
})(TotoWidgets || {});

Mais c’est dommage. On est ici dans le cas typique où :

• ta méthode ne renvoie rien
• elle est en fait, conceptuellement, un gestionnaire d’événement… pour un événement « un morceau de la page a changé » qui n’existe pas (ou pas forcément)

Une solution plus discrète (dans le sens où elle ne te force pas à publier quelque API que ce soit) consisterait à utiliser un événement personnalisé, que tu déclencherais par exemple au niveau de la zone qui a changé (avec un bête .trigger), et que ton module écouterait au niveau document. Ça donnerait quelque chose comme ça :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28

// Dans ton module de widget :
(function() {
  var knownWidgets = {};

  function initWidgets(e) {
    var zone = $(e.target || document.body);

    zone.find('input[type=date], input.date').each(function(i, element) {
      element.id = element.id || _.uniqueId('datePicker');

      if (knownWidgets[element.id])
        return;

      knownWidgets[element.id] = new MyDatePickerWidget(element);
    });
  }

  $(function() {
    initWidgets();
  });
  $(document).on('pageupdate.ui', initWidgets);
})();


// Dans le code qui modifie un morceau de la page (ex. Ajax) :
$('ul#files').load('/files', function() {
  $(this).trigger('pageupdate.ui');
});

Dans l’idéal, tu « standardises » ces événements custom à travers toute la couche UI de ton code JavaScript, de sorte que ça devient une sorte d’habitude pour tous tes widgets internes, etc. En fait, ce n’est ni plus ni moins que du publish/subscribe (ou si tu préfères, observateur/observé)), mais avec le bouillonnement en plus, et donc la notion de zone DOM concernée.

7. Proposer un hash d’options plutôt qu’une signature à rallonge

Lorsqu’on écrit une masse minimum de code (à partir de quelques fonctions, surtout si elles sont publiques), il est toujours bénéfique de réfléchir à l’API design, c’est-à-dire à la conception générale de l’API ainsi produite. Qui utilisera ce code ? Comment ? Pour quels besoins ? Dans quels contextes ? Ce type de recul et de mise en perspective est hélas trop rare, même chez les designers d’API chevronnés, comme en attestent nombre d’exemples proéminents. Pour n’en citer que quelques-uns :

• jQuery.each, le seul itérateur à ma connaissance à coller l’index en premier plutôt que la valeur, source à lui seul de semaines-hommes entières perdues chaque jour à l’échelle mondiale…
• L’API XSL/T du JDK ; le cas dominant (90% du besoin) étant l’application d’une feuille XSLT sur un document XML, cette situation requiert… une bonne douzaine de lignes de code.
• Dans le même esprit, le module Net::HTTP de Ruby. Prendre en charge HTTPS ou simplement traverser les redirections, deux besoins ultra-basiques, nécessitent quelques lignes de code non trivial.
• XMLHttpRequest : outre sa casse discutable (XML en majuscules mais Http en casse Camel ?!), le cas de base Ajax nécessite une demi-douzaine de lignes de code, ce qui a immédiatement entraîné nombre de wrappers, au point qu’aujourd’hui peut-être un développeur front-end sur mille connait l’API d’origine…
• Au bas mot la moitié de l’API standard PHP : entre les paramètres jamais placés dans l’ordre intuitif, les casses variables, les ordonnancements aléatoires dans les noms de fonctions, etc. c’est un des plus emblématiques foutoirs du développement contemporain.

Bien concevoir une API change radicalement sa facilité de découverte et d’apprentissage, et le plaisir qu’on a à l’employer. Je ne saurais trop vous conseiller à cet égard l’excellente conférence de Jake Archibald à Paris Web 2010 : Reusable Code: For Good or For Awesome, qui regorge d’exemples concrets et d’humour ravageur.

Un des points les plus critiques du design d’une API reste pour moi la signature des fonctions/méthodes publiques. En particulier le passage à un hash d’options au lieu de paramètres positionnés dès lors qu’on dépasse, disons, 3 paramètres, ou que ceux-ci ont le même type de données attendu. Ainsi, on obtient un effet similaire aux paramètres nommés dans certains langages, ce qui fait que les appels à la fonction sont en quelque sorte « auto-documentés ».

Personne n’aime tomber sur du code de ce genre :

1
2
3

Toolkit.initWidgets('container', true, false);

bindConnectors(25, '', 'foo', true, 1000);

Quand on tombe sur ce code, que ce soit celui d’un autre ou le nôtre il y a 3 mois (ce qui revient au même), on se demande automatiquement « mais ?! Ça fait quoi ce true ? », et ce pour pratiquement chaque paramètre.

On préfèrerait tous tomber sur ceci :

1
2
3

Toolkit.initWidgets('container', { autoBind: true, hideNative: false });

bindConnectors({ interval: 25, separator: '', container: 'foo', autoRefresh: true, delay: 1000 });

Dans le même esprit, ce n’est pas parce qu’une fonction propose une trentaine d’options que je dois me les fader à chaque fois. De ce point de vue, les fonctionnalités Ajax de jQuery sont un excellent exemple de conception pratique : $.ajax et ses aliases/wrappers, tels $.get ou $(…).load, sont tous conçus avec un hash d’options et des valeurs par défaut bien adaptées à la majorité des cas.

Mettre en place ce type de fonction ne nécessite pas forcément plus de travail que pour une fonction à la signature plus directe. Parfois, ça en nécessite même moins.

Avant d’écrire le code à l’intérieur d’une fonction à la signature non triviale, je vous encourage à la documenter immédiatement. Cash, juste au-dessus de la déclaration, dans un commentaire. Et surtout, surtout, mettez-y des exemples concrets d’appels. Ce n’est qu’en vous forçant ainsi à considérer les choses du point de vue « code appelant » (utilisateur, donc) que vous verrez rapidement si la signature que vous aviez initialement imaginée est adaptée ou doit être repensée. Et c’est à ce moment-là, alors qu’aucune ligne de code n’a été écrite encore dans la fonction, que le refactoring de la signature n’a aucun coût supplémentaire.

Ensuite, écrire une telle fonction repose sur quelques principes simples :

• passer à un hash d’options dès qu’on dépasse 3-4 paramètres, ou qu’on a au moins deux paramètres de même type (donc ambigüs à l’appel)
• fournir des valeurs par défaut clairement regroupées et explicitées pour toutes les options, voire pour certains paramètres.
• si on propose plusieurs signatures (de la plus courte pour les cas majoritaires à la plus longue pour un cas sur-mesure), normaliser vers la signature longue avant le reste du code, afin de n’écrire qu’une version de l’implémentation.

Prenons pour exemple une fonction callAjax dans l’esprit de celle de jQuery. En documentant ses appels avant de l’implémenter, on isole plusieurs types d’appel afin d’être pratique à appeler pour tous :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

// Makes an Ajax call.  This can be called in a very concise way, with just the endpoint
// URL, if you don't care about callbacks or behavior changes (the URL will be called through
// HTTP GET).  You can also specify just a success callback, or a success and an error, or
// provide a full-blown options hash to fine-tune the behavior.
//
// Example calls:
//
//   callAjax('/files')
//   callAjax('/files', function success(res) { … })
//   callAjax('/files', successCallback, errorCallback)
//   callAjax('/files', {
//     method: 'POST',
//     dataType: 'json',
//     success: function ajaxSuccess() { … },
//     error: function ajaxError() { … }
//   })
function callAjax() {

}

Pour une signature polymorphe comme ici, on a plusieurs choix quant à la signature formelle (la liste des paramètres) de la fonction :

• ne rien mettre et tout traiter dynamiquement dans la fonction via arguments
• ne poser que les paramètres invariables (ici l’URL) et gérer le reste via arguments
• faire un mix des deux…

Nous allons opter ici pour la deuxième approche. L’idée est de normaliser l’appel vers sa version la plus complexe, donc avec un hash d’options. On commencerait donc comme ceci :

1
2
3
4
5
6
7
8

function callAjax(url) {
  var options = arguments[1] || {};

  if (_.isFunction(options)) {
    options = { success: options, error: arguments[2] };
  }
  // …
}

On gère ainsi les cas suivants :

• pas de deuxième argument (ou deuxième argument falsy, ce qui n’est pas valide pour notre signature) : options est un objet vide ({})
• le deuxième argument est une fonction : il s’agit alors du callback de succès, éventuellement suivi de celui d’erreur : on normalise vers un hash d’options avec les deux clés appropriées. Faute de troisième argument, options.error sera présent mais vaudra undefined.
• le deuxième argument est un hash d’options : on n’y touche pas.

Pour gérer les valeurs par défaut, il suffit de définir un conteneur pour toutes celles-ci et de fusionner dans options toutes les clés absentes ou dont la valeur est undefined. On documente en général les valeurs possibles pour chaque option en écrivant le conteneur. Un emplacement plutôt valable pour celui-ci est une propriété defaults ou defaultOptions sur la fonction :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

callAjax.defaults = {
  // Possible data types are 'html', 'json', 'js', 'jsonp' and 'xml'
  dataType: 'html',

  // Error callback.  Called with the response text and XHR object.
  error: $.noop,

  // HTTP verb.  If not 'GET' or 'POST', will emulate using a 'POST' and injecting
  // a `_method` parameter with the passed verb.
  method: 'GET',

  // Success callback.  Called with the response text (or parsed object according to
  // `dataType`) and XHR object.
  success: $.noop
};

Il est ainsi facile pour l’utilisateur de modifier globalement les valeurs par défaut. Si on souhaite interdire ça par mesure de sécurité/compatibilité, et qu’on est sur une runtime ES5, on peut toujours faire suivre la définition d’un Object.freeze(callAjax.defaults). Une autre approche consisterait à enfermer la fonction et ses défauts dans une closure et ne publier que la fonction.

Pour exploiter ces paramètres par défaut, rien de plus simple. Une fois options normalisé dans la fonction, on procède ainsi :

1
2
3
4

for (var opt in callAjax.defaults) {
  if (_.isUndefined(options[opt]))
    options[opt] = callAjax.defaults[opt];
};

En fait, ce type de schéma est si fréquent qu’il porte un nom usuel : extend. On en trouve des implémentations globalement équivalentes dans la majorité des bibliothèques, de jQuery à Prototype en passant par Underscore. Du coup, le code plus fréquent pour ce type de besoin est le suivant :

1

options = $.extend({}, callAjax.defaults, options);

Le reste du code de la fonction n’a plus qu’à exploiter les arguments fixes (url) et le contenu d’options.

8. Ne pas concaténer en masse les chaînes

En JavaScript il est fréquent de devoir construire petit à petit une chaîne de caractères massive ; il s’agit le plus souvent de HTML qu’on compose au fil de l’eau, à la main faute de mécanisme de templating. Vous savez, ce genre de code :

1
2
3
4
5
6
7
8
9
10

// BEUARK
function buildHTML(names) {
  var result = '<ul>';

  for (var index = 0, len = names.length; index < len; ++index)
    result += '<li>' + _.escape(names[index]) + '</li>';
  result += '</ul>';

  return result;
}

Ce genre de code est très peu performant. C’est comme en Java : une String est non modifiable, et du coup += entraîne à chaque fois la création d’une nouvelle chaîne, ce qui implique qu’il faudra nettoyer la mémoire occupée par la précédente. Et plus c’est long, plus c’est lourd.

Tout comme on recommande en Java de recourir à StringBuffer voire StringBuilder, en JavaScript la meilleure approche consiste à enquiller les fragments dans un tableau, pour au final faire le join qui regroupe tout ça :

1
2
3
4
5
6
7
8
9

function buildHTML(names) {
  var result = ['<ul>'];

  for (var index = 0, len = names.length; index < len; ++index)
    result.push('<li>' + _.escape(names[index]) + '</li>');
  result.push('</ul>');

  return result.join(''); // ou join('\n')
}

Les performances n’ont rien à voir, surtout sur de grandes quantités. Et pour les petites, le code n’est pas plus compliqué, alors autant normaliser…

9. Réutiliser ses gros tableaux

Il arrive de temps en temps qu’on ait fini de bosser sur un tableau et qu’on veuille repartir sur un « tableau neuf ». Parfois, ce sont de très gros tableaux, comme par exemple ceux qu’on utilise pour calculer un filtre sur les pixels d’un <canvas>… On a alors tendance à faire :

1
2
3
4

// travail sur un tableau "arr" qui devient maousse…

// « remise à zéro » -- SAYBOF
arr = [];

En fait, cette affectation est sans surprise : elle envoie l’ancien tableau à la casse (il faudra en récupérer la mémoire) et crée un nouveau tableau, tout petit, qui devra donc lui aussi demander toujours davantage de mémoire au fil de son utilisation. C’est un peu dommage d’avoir basardé toute cette RAM alors qu’on en aura sans doute besoin juste après. Et jouer avec new Array(length) ne change rien à l’affaire : ça ne préalloue pas la mémoire pour autant.

Mais surprise ! La propriété length d’un tableau est en lecture/écriture. On peut donc s’en servir pour réutiliser un tableau existant et sa mémoire allouée, comme ceci :

1
2
3
4

// travail sur un tableau "arr" qui devient maousse…

// « remise à zéro » -- La classe
arr.length = 0;

Là aussi, les perfs obtenues sont largement meilleures pour les cas où les tableaux grandissent significativement au fil du temps.

10. Convertir les nombres correctement

Figurez-vous que parseInt est un menteur doublé d’un salaud et que parseFloat est juste la version pourrie de Number(…). Après cette phrase un brin raccoleuse (mais parfaitement véridique), je vous invite à consulter tous les détails dans l’article que je publiais fin décembre : Convertir un texte en nombre en JavaScript

Envie d’en savoir plus ?

Nos ateliers de formation JavaScript couvrent ce genre d’aspects explicitement ou à travers tous leurs codes, et beaucoup, beaucoup plus encore. Jetez-y un œil, en plus ils sont bien moins chers que la moyenne du marché !

• JS Puissant s’intéresse au langage lui-même, y compris pour des usages très avancés.
• JS Guru explore l’écosystème front-end en détail et permet la réalisation de bout-en-bout d’une Single-Page App ultra-moderne mettant en œuvre de façon intégrée tout plein de technos « HTML5 » à l’aide d’un outillage développeur de premier plan.
• JS Total reprend les deux autres et rajoute les problématiques de tests automatisés, documentation, optimisations tous azimuts et web mobile.

La session JS Guru des 22 et 23 janvier (oui, c’est la semaine prochaine) se dirige droit vers une annulation, faute d’avoir suffisamment d’inscrits. C’est particulièrement dommage, car avec la JS Total de février déjà complète, elle constitue une bonne alternative (surtout en duo avec la JS Puissant de février) pour bénéficier des contenus les plus « sexy » de JS Total.

Nos conditions d’annulation étant ce qu’elles sont, nous devrons statuer sur cette session au plus tard demain après-midi.

Nous avons donc décidé de tenter une petite opération de réduction visant à ramener assez de places pour la maintenir. Pour ces dates uniquement, nous baissons donc tous les tarifs de 100€ HT, ce qui donne, par personne :

• 799€ HT seulement (jusqu’à 2 personnes)
• 699€ HT seulement (de 3 à 5 personnes)
• 599€ HT seulement (à partir de 6 personnes)
• 664€ HT seulement (tarif fidélité : votre société nous a réglé au moins 1000€ HT sur les 12 mois écoulés)

Notez que vous pouvez constituer un groupe multi-sociétés : si vous nous adressez une demande de convention précisant l’ensemble des noms et infos de société, nous pourrons appliquer le tarif de groupe approprié à l’ensemble des participants concernés.

Comme le programme devrait vous en convaincre, c’est une formation très alléchante. À un tarif pareil, il n’y a pas à hésiter !

(et dans la même série, on a deux sessions Git à la fin du mois qui ont encore plein de places et sont super intéressantes : Git au Quotidien le 29 et Git Avancé le 30)

Delicious Insights et son cycle de formations JS Attitude vous souhaitent une excellente nouvelle année, avec plein de bonnes choses dedans, et notamment davantage de plaisir au travail. C’est le moment de planifier vos formations pour ce début d’année ! Et JS Attitude vous propose bon nombre de sessions pour le premier trimestre :

• 22–23/01 : JS Guru en format 2 jours (dépêchez-vous !). Outre son intérêt propre, cette session fournit une alternative intéressante pour tous ceux qui ne pourront pas assister à JS Total en février, faute de places…
• 05–08/02 : JS Total ; notre blockbuster a toutefois, comme d’habitude, affiché complet 6 semaines avant la date… Une excellente alternative, qui est aussi légèrement meilleur marché, consiste à s’inscrire au JS Guru 2 jours des 22–23/01 et au JS Puissant du 19/02, ce qui vous fournit à peu près 80% des savoirs dispensés par JS Total. Il reste pas mal de places sur ces 2 sessions. La prochaine JS Total n’aura lieu qu’en avril (dates à venir).
• 19/02 : JS Puissant, une formation qui à mon sens constitue un incontournable pour tout développeur JS sérieux.
• 26/02 : CoffeeScript. La voie royale vers (beaucoup) plus de bonheur dans votre JavaScript quotidien. Contrairement à fin 2012, les places pour cette session partent assez vite, alors dépêchez-vous !
• 18–19/03 : JS Guru en format 2 jours

Dépêchez-vous de demander une convention de formation. Et souvenez-vous : Delicious Insights est un organisme de formation agréé, éligible aux prises en charge par OPCA (dont les DIF), nous sommes presque moitié moins chers que le marché en dépit de prestations haut de gamme et en avance sur ce dernier, et nous ne demandons pas de versement d’acompte : vous réglez jusqu’à 30 jours après la session ! Alors n’hésitez plus !

Sachez par ailleurs qu’il nous reste comme disponibilités pour de l’intra-entreprises :

• 1 jour en janvier (24, 25 ou 31)
• 2 jours en février (20, 21, 22, 27 ou 28)
• plus rien en mars (!)

Et pourtant… Que de pièges, que de subtilités de fonctionnement nous attendent sur un sujet au premier abord aussi basique. Explorons tout ça ensemble.

A-t-on besoin de convertir ?

Comme bien souvent, la vraie réponse est : ça dépend.

Dans la mesure où je vous recommande par ailleurs de toujours comparer avec === sauf cas spécifique bien identifié, vous aurez en effet besoin, si vous appliquez cette consigne, de convertir explicitement vos nombres « textuels » en nombres effectifs (type Number) pour obtenir une comparaison valide.

Toutefois, certains opérateurs qui n’ont de sens que sur les nombres (ou principalement sur les nombres) entraîneront automatiquement une conversion numérique de leurs arguments. On parle alors de protocole de conversion implicite. C’est notamment le cas des opérateurs arithmétiques, à l’exception du cas « String plus quelque chose ». Toutefois, l’enchaînement de protocoles de conversion, chaque opérande étant traité indépendamment et à tour de rôle, peut donner à terme des String là où on aurait cru des Number, ce qui n’est pas sans surprise…

1
2
3
4
5
6
7
8
9
10
11
12

5 + 2           // => 7
'5' + 2         // => '52'
5 + '2'         // => '52'
'5' + '2'       // => '52'
[] + 3          // => '3'
3 + []          // => '3'
{} + 3          // => 3 ou '[object Object]3', selon version de JS
3 + {}          // => '3[object Object]'
false + 3       // => 3
3 + true        // => 4
3 + null        // => 3
var x; x + 3    // => NaN

Dans les exemples ci-dessus, on voit que l’opérateur + entraîne souvent des conversions amenant à String, mais propose aussi pas mal de cas où le résultat est, de façon inattendue parfois, un Number. Les opérateurs moins ambigüs, tels que - ou *, fonctionnent presque toujours en Number (par exemple, 3 - [] est toujours 3), quitte à renvoyer NaN (qui comme son nom ne l’indique pas est bien de type Number…).

Le problème, évidemment, c’est qu’on ne va pas commencer à se souvenir de tous les cas de figure, opérateur par opérateur, et types d’opérande par types d’opérande. D’où la nécessité de clarifier parfois les choses en forçant explicitement le type de nos opérandes à Number, de façon contrôlée.

Pour ce faire, la majorité des auteurs de code JavaScript ont recours, suivant le besoin (entier ou flottant), à parseInt et parseFloat. À mon sens, c’est plus problématique qu’autre chose.

Méfie-toi de parseInt et parseFloat

Les deux ne se comportent pas exactement pareil. Comme leurs noms l’indiquent, le premier renvoie un entier (un Number tronqué sur sa partie entière) et l’autre un flottant (toujours un Number, mais non tronqué). Mais ce n’est pas tout. Par exemple, avant ES5 (testez sur une console JS qui ne force pas ES5, ou dans une REPL node par exemple), on obtenait ceci :

1
2
3

// Pre-ES5 -- consoles Firefox, Safari, node, etc.  Mais pas Chrome !
parseFloat('08') // => 8
parseInt('08')   // => 0 -- OMGWTFBBQ?!

C’est un problème bien connu : parseInt accepte en fait deux arguments : le texte et une base optionnelle (de 2 à 36) dans lequel ce texte encode le nombre. Mais avant EcmaScript 5, au lieu de supposer une base 10 (ce qui, de l’avis général, serait nettement plus utile), il devine. Aïe. En l’occurrence, il se base sur les syntaxes C/Java/JS/etc. de litéraux entiers, donc démarrer par 0x ou 0X indique un hexadécimal, sinon démarrer par 0 indique un octal ; les chiffres octaux valides allant de 0 à 7, le 8 est invalide.

Incidemment, JSLint (comme JSHint, je crois) vous couineront à l’oreille s’ils vous voient faire un parseInt qui ne précise pas la base. Et ils auront raison.

Vous me direz : « mais alors, parseInt('08') devrait plutôt renvoyer NaN, non ?! ». Et je serais bien d’accord avec vous. Seulement voilà : parseInt et parseFloat se contentent d’ignorer la suite du texte dès qu’ils rencontrent un caractère invalide. Ce qui est un comportement pourri, mais toujours d’actualité.

Je ne sais pas vous, mais moi, si je demande à l’internaute de saisir un nombre et qu’il me pond 42foobar, je ne veux pas « voir » 42, je veux me prendre un NaN. Pas de chance :

1
2

parseInt('42foobar', 10) // => 42
parseFloat('42foobar')   // => 42

Alors que faire ?

Le protocole de conversion numérique de JavaScript

Il se trouve que JavaScript est depuis toujours équipé d’un mécanisme qui convertit une entité quelconque en Number : c’est son protocole de conversion numérique, que la spec appelle affectueusement « ToNumber ». Il est déclenché implicitement lors d’expressions nécessitant un traitement numérique d’un opérande.

La manière la plus simple de transformer une valeur (ou undefined) en Number consiste probablement à la passer à l’opérateur + unaire (c’est-à-dire ne prenant qu’un opérande) : +truc. Bon point pour lui : il refusera tout caractère invalide. Voyez plutôt :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

+42          // => 42
+'42'        // => 42
+'08'        // => 8
+'0x10'      // => 16
+'42.17'     // => 42.17
+'42foobar'  // => NaN -- aaaaah !
+'   42   '  // => 42
+{}          // => NaN -- pas de conversion générique Object -> Number
+[]          // => 0 -- <=> +([].toString()) <=> +''
+[3]         // => 3 -- <=> +'3'
+[3, 4]      // => NaN  <=> +'3,4'
+false       // => 0
+true        // => 1
+null        // => 0
var x; +x    // => NaN

Comme vous pouvez le voir, le + unaire est un moyen rapide, concis et efficace de convertir ce qu’on veut en Number. Il ne change pas le signe éventuel et réagit à tout caractère invalide en retournant NaN. Il est donc en tous points supérieur à parseFloat.

Il faut souligner qu’il existe une manière plus explicite de déclencher la conversion : il suffit d’employer Number comme fonction, conformément à la section 15.7.1.1 de la spec (ES3) :

1
2
3
4
5

Number('0x10')      // => 16
Number('42.17')     // => 42.17
Number('42foobar')  // => NaN
Number(false)       // => 0
var x; Number(x)    // => NaN

C’est certes un peu plus verbeux que le + unaire, mais nettement plus lisible pour les débutants…

Le seul souci potentiel, c’est que ce protocole de conversion ne fournit pas d’équivalent à parseInt, au sens où il ne tronque jamais sur la partie entière. Comment obtenir ce comportement ? Selon que vous voulez préserver un résultat NaN sur les textes pourris ou non, la solution varie.

Et pour garantir des entiers ?

On a deux manières de procéder :

• une qui est aussi performante que possible mais ignore les infinis et les NaN
• une qui est plutôt lisible et préserve les infinis (sait-on jamais…), au prix d’une performance très légèrement inférieure (ce qui n’est généralement pas un souci).

Voyons-les tour à tour.

La méthode « hack », ultra-performante mais peu lisible et non sans limites

À condition que ça ne vous dérange pas d’être à zéro par défaut (textes moisis compris), vous pouvez tirer parti de la sémantique de l’opérateur ou bit-à-bit, à savoir le pipe simple (|) :

1
2
3
4
5
6
7
8

42.17 | 0       // => 42
-42.3 | 0       // => -42
'42'  | 0       // => 42
'42.13' | 0     // => 42
'-17.7' | 0     // => -17
'0x10' | 0      // => 16
'42foobar' | 0  // => 0 -- pas NaN
'xyz' | 0       // => 0 -- pas NaN

À ce stade, vous avez probablement trois questions :

• Pourquoi est-ce que ça force les entiers ? C’est parce que selon la section 11.10 de la spec (pour ES3 en tout cas, mais la sémantique persiste en ES5), les opérandes sont passés par une conversion interne ToInt32, pour en faire des entiers signés 32-bit (oui, attention, pas 64-bit !).
• Pourquoi est-ce que ça ne fait pas de NaN ? Parce que la spec de ToInt32 revient à passer par ToNumber puis, pour tous les cas « foireux » (NaN, zéros signés et infinis), à remplacer par 0 (section 9.5 de la spec ES3).
• Pourquoi le OU et pas une autre opération bit-à-bit ? Il nous faut une opération neutre sur l’entier d’origine (le résultat du ToInt32 sur votre texte). Passer par un ET (&) serait donc assez pénible car il nous faudrait un masque intégral, alors que le OU (|) et le OU exclusif (XOR, ^) sont neutres à zéro. J’imagine que le pipe a gagné de peu sur le caret parce qu’il est plus souvent tapé…

Petit conseil d’ami : si vous employez une telle syntaxe, ajoutez un commentaire sur la ligne précédente indiquant que vous faites une conversion entière à zéro par défaut : ce n’est vraiment pas lisible tel quel…

OK, mais si je veux du NaN pour les textes moisis ?

C’est en effet un cas de figure probable. Pour le gérer correctement, vous devrez probablement combiner la conversion ToNumber classique et le déclenchement implicite de ToInt32 au moyen d’un ou bit-à-bit :

1
2
3
4
5
6
7
8

function cleanInt(x) {
  x = +x; // x = Number(x);
  return isNaN(x) ? x : (x | 0);
}

cleanInt('-42.17')   // => -42
cleanInt('42foobar') // => NaN
cleanInt('Infinity') // => 0 -- hmmm…

La méthode un poil moins performante, mais lisible et universelle

Quitte à faire une fonction dédiée, autant préserver les infinis aussi. Pour cela, plutôt que de passer par l’absconse syntaxe | 0, utilisons les fonctions d’arrondi de JavaScript. C’est certes un micro-poil moins rapide, mais ça ne devrait généralement pas nous poser de souci concret.

1
2
3
4
5
6
7
8
9

function cleanInt(x) {
  x = Number(x);
  return x >= 0 ? Math.floor(x) : Math.ceil(x);
}

cleanInt('-42.17')    // => -42
cleanInt('42foobar')  // => NaN
cleanInt('Infinity')  // => Infinity
cleanInt('-Infinity') // => -Infinity

Examinons les cas possibles :

• x est un texte moisi ou x est NaN : il sera NaN au final, la condition sera fausse (toute comparaison de NaN renvoie false) et Math.ceil préservera NaN.
• x décrit un nombre valide positif ou nul : on utilisera l’arrondi à l’entier immédiatement inférieur, Math.floor.
• x décrit un nombre valide négatif : on utilisera l’arrondi à l’entier immédiatement supérieur, Math.ceil.
• x décrit un infini positif ou négatif : Math.floor comme Math.ceil préserveront l’infini concerné.

En fait, le ternaire (l’opérateur … ? … : …) ci-dessus se prête particulièrement bien à une petite optimisation syntaxique, sans nuire pour autant—à mon sens—à la lisibilité, au moyen de l’opérateur [] qui permet de sélectionner dynamiquement une propriété (donc une méthode) au sein d’un objet :

1
2
3
4

function cleanInt(x) {
  x = Number(x);
  return Math[x >= 0 ? 'floor' : 'ceil'](x);
}

En résumé…

• parseInt et parseFloat sont juste bons à sucer des cailloux
• Le + unaire, ou sa version explicite Number(…), sont souvent supérieurs à parseFloat car ils renvoient NaN pour les textes moisis
• Le … | 0 tronque bien sur la partie entière, mais renvoie 0 pour les textes moisis
• On peut facilement combiner les deux pour obtenir une version plus clean de parseInt(…, 10)
• On peut aussi choisir de sacrifier quelques microsecondes (ahem…) pour gagner en lisibilité en préservant au passage les infinis.

Et lorsqu’on instancie un objet en JavaScript, on fait généralement new LeType(…). Mais dans cet article, je vais vous expliquer pourquoi, à quelques petites exceptions près, pour les types natifs c’est soit inutilement lourd, soit carrément contre-productif.

Allez, on se démonte les types un par un, d’accord ?

Object

De deux choses l’une :

• soit tu veux instancier un type à toi, et tu vas faire new TonType, pas new Object ;
• soit tu veux bien un objet basique tout nu, et alors tu auras largement plus vite fait d’utiliser {} (ex. var obj = {};). La version new est inutilement verbeuse, car on a une syntaxe litérale disponible. Ce sera aussi le cas de plusieurs autres types natifs.

Number

OK, donc tu veux créer un nouveau nombre. Explique-moi pourquoi tu irais faire new Number(42) au lieu de juste 42 ?!? Tu es payé(e) au caractère ? Évidemment pas.

En plus, les deux ne se comportent pas de la même façon dans certains cas. Par exemple, le protocole de conversion booléenne n’est pas le même : if (new Number(0)) passera alors que if (0) non.

String

Là aussi, on a une syntaxe litérale : les apostrophes ou guillemets (aucune différence dans le comportement). Aucune raison de t’embarasser d’un new String('foobar') lorsque l’argument, 'foobar', suffit.

Qui plus est, JavaScript va traiter différemment les objets String (issus d’un new String(…)) et les chaînes primitives (produites par un litéral). Ainsi, typeof new String('foo') produit 'object' et non 'string'. Et eval ne considèrera comme code source qu’une chaîne primitive, alors qu’un objet String sera juste renvoyé tel quel. Autant de raisons de ne jamais recourir à new String…

Boolean

On est dans une situation similaire à Number : non seulement les deux litéraux réservés true et false sont suffisants, mais en plus le protocole de conversion booléenne va nous foutre dedans : if (new Boolean(false)) passera ! Une bonne raison de ne jamais recourir à new sur ce coup…

Array

Dans la mesure où on a une syntaxe litérale (crochets et virgules, ex. [1, 2, 3]), il n’y a a priori jamais à utiliser new Array(1, 2, 3)…

Il existe juste un cas, finalement assez rare, où le new est toutefois justifié : pour préallouer un tableau à une certaine taille, ce qui se produit si on utilise un unique argument numérique. Par exemple, new Array(1000000) va créer un tableau d’un million de cases, toutes pour le moment undefined. Encore une fois, c’est un cas de figure assez rare.

Date

Pour le coup, new Date est parfaitement justifié, puisqu’on initialise très souvent un objet Date sur la base d’une valeur précise, que celle-ci soit un numérique (nombre de millisecondes depuis l’epoch, le 1er janvier 1970 à 0h GMT), une chaîne de caractère compatible ou une série de composantes année, mois, jour, etc. Il n’y a tout simplement pas de syntaxe litérale pour les dates, on doit donc recourir à new Date.

Il existe toutefois un cas où je déconseille new Date : lorsqu’on veut juste récupérer la version numérique du moment présent. Plutôt que de faire new Date().getTime(), préférez Date.now() : non seulement c’est nettement plus compact et explicite, mais en plus ça évite de créer inutilement un objet Date à garbage-collecter ensuite…

RegExp

On a ici deux cas de figure :

• La regex est fixe, connue à l’avance. Il est alors inutile de passer par new RegExp, puisqu’on dispose d’une syntaxe litérale. /foo(?:bar)?/ig sera toujours plus court que new RegExp('foo(?:bar)?', 'ig')… Cependant, si la regex est bourré de slashes (/), je peux comprendre qu’au bout d’un moment on préfère éviter de tous les échapper : new RegExp('^https?://foo/bar/baz') peut sembler préférable à /^https?:\/\/foo\/bar\/baz/…
• La regex n’est pas connue à l’avance. Par exemple, elle est calculée sur la base d’une saisie utilisateur, d’une réponse Ajax, etc. Auquel cas on n’a pas d’autre choix que de passer par new RegExp. Imaginons qu’on développe un fuzzy matcher qui cherche toutes les chaînes de caractères contenant ceux qu’on saisit, dans le bon ordre mais quelles que soient leurs positions, comme dans les éditeurs TextMate et SublimeText :

1
2
3
4
5
6
7
8
9
10
11
12
13
14

var words = ['déjà', 'demain', 'délicat', 'dommage', 'foobar'];
var input = 'da'; // On l'aurait par exemple prix de $('#search').val()…
var regex = new RegExp(input.split('').join('.*'), 'i'); // => /d.*a/i

var result = [], word;
for (var index = 0, len = words.length; index < len; ++index) {
  word = words[index];
  if (regex.test(word))
    result.push(word);
}

// Ou avec Prototype : var result = words.grep(regex);

result // => ['demain', 'délicat', 'dommage']

Function

Il existe trois manières de créer des fonctions en JavaScript :

• Avec une déclaration : c’est ce qui se passe quand le mot-clé function est rencontré à un endroit où on attend une instruction. Il doit alors obligatoirement être suivi d’un identifiant qui nomme la fonction. Les déclarations de fonction sont hoisted, c’est-à-dire qu’elles sont interprétées comme si elles étaient placées en tout début de portée (donc de l’éventuelle fonction conteneur).
• Avec une expression : c’est le cas quand le mot-clé function est rencontrée alors qu’on attend une expression (par exemple, à droite d’un opérateur =, d’une parenthèse ouvrante, ou comme argument à une autre fonction). La fonction n’est pas obligatoirement nommée (et si elle l’est, ce nom n’est valable qu’à l’intérieur de la fonction elle-même), et n’est pas non plus hoisted.
• Avec new Function. Cela permet de créer une fonction dont le code a été déterminé dynamiquement à l’exécution, mais attention, il existe une différence majeure : là où les déclarations et expressions de fonction entraînent une closure (une fermeture lexicale, qui leur permet d’accéder à l’ensemble de la portée), les fonctions obtenues par new Function s’exécutent dans le contexte global (dans un navigateur, l’objet window), voire, si on est en EcmaScript 5 et en mode strict (le texte de la fonction démarre par 'use strict';), avec un contexte undefined.

L’immense majorité du temps, votre fonction a besoin de sa closure : vous aurez donc recours à une expression de fonction ou à une déclaration.

Dans certains cas très rares toutefois, tels qu’une évaluation de code arbitraire que vous souhaiteriez « protéger » en lui interdisant tout accès à la closure en vigueur, recourir à new Function, surtout en mode strict si ça vous est possible, est une alternative viable, et souvent préférable, à un bête eval.

Conclusion

Comme vous pouvez le voir, au quotidien, il est généralement inutile de recourir à new pour les types natifs, à l’exception notable de new Date et, de temps en temps, de new RegExp. Les cas valables de new Array et new Function sont rares, pour ne pas dire rarissimes, et tous les autres cas sont inutiles voire contre-productifs, au sens où ils entraînent des comportements inattendus et sources de bugs.

J’espère que cette petite balade à travers la sémantique des types natifs et les distinctions, souvent subtiles, entre les valeurs dites primitives et leurs équivalents objets vous aura intéressé, et qui sait, peut-être même éclairé sur des accrocs passés.

1. JS Puissant le 08/01 et le 19/02
2. JS Guru en format étendu 2 jours les 22 et 23/01
3. JS Total du 05 au 08/02 ! Vous étiez nombreux à attendre cette nouvelle date, la session de décembre 2012 étant complète. Alors dépêchez-vous de vous inscrire pour ne pas arriver trop tard cette fois-ci !
4. CoffeeScript le 26/02

En revanche, en raison d’un nombre d’inscriptions véritablement trop faible d’une part, et de besoins intra-entreprises trop forts d’autre part, nous avons dû annuler préemptivement la session Coffee Guru du 19 au 21/12.

N’attendez pas ! Demandez rapidement vos conventions pour ces nouvelles dates !

En 2006 puis 2007, désormais doté d’une documentation solide et d’une équipe de développement (Prototype Core) compétente, motivée et très active, il était incontournable.

Avance rapide sur 2012 : plus personne (ou presque) n’en parle. On entend encore un peu parler de MooTools, Dojo, YUI… Et le grand vainqueur est jQuery, ce framework à l’écosystème gigantesque et vivace, à tel point qu’on est obligé d’expliquer au plus grand nombre la différence entre jQuery et JavaScript.

Que s’est-il passé ?

Ce petit article un peu nostalgique vous explique pourquoi Prototype a sombré et où il en est aujourd’hui.

Full Disclaimer

Je suis moi-même un ancien de Prototype Core. En 2006, avec Bien Développer pour le Web 2.0, je produisais la première documentation exhaustive du framework, alors en version 1.4.

Durant l’hiver, j’étais l’un des trois co-auteurs du site officiel de documentation, et en janvier 2007 je rejoignais le noyau des développeurs pour produire, au fil des mois, les versions 1.5, 1.5.1 (qui était absolument géniale à l’époque) puis 1.6. En 2008, je publiais la référence, Prototype and script.aculo.us, chez les Pragmatic Programmers.

2005–2008 : l’âge d’or

C’était une période dorée. L’équipe était petite mais très active : Sam Stephenson, Andrew Dupont, Tobie Langel, Mislav Marohnić, Juriy Zaytsev et Thomas Fuchs, le créateur de script.aculo.us, plus votre serviteur.

On bossait beaucoup et ça se voyait, Prototype dominait complètement le marché des bibliothèques médianes, qui simplifiaient Ajax et le DOM mais aussi la création d’algorithmes compliqués et de systèmes de classes.

La décroissance

Et puis, presque du jour au lendemain, jQuery a pris presque toute la place. Les raisons sont multiples, mais ses forces principales étaient évidentes :

• Une cible plus étroitement définie mais majoritaire sur le marché : les intégrateurs HTML/CSS qui ne veulent pas apprendre JavaScript trop en profondeur : ils veulent « juste » des effets visuels, des animations simples et de l’Ajax simplifié.
• Une syntaxe facile et laxiste, triviale à apprendre, ne demandant que très peu d’efforts et de rigueur
• Une équipe volumineuse
• Une vraie force de frappe marketing, avec des tonnes de docs, tutorials, meetups, événements communautaires puis conférences, bouquins…

Alors que jQuery ne cessait de grandir, épaulée par le statut Mozillien de John Resig et une forte attention portée à sa communauté, pour atteindre rapidement de très nombreuses personnes dédiées à temps plein, Prototype, lui, voyait son équipe se réduire comme peau de chagrin.

Nous avions tous un boulot à temps plein à côté, nous étions peu nombreux, nous nous concentrions sur le code et n’accordions que très peu de temps à la visibilité de Prototype. Et jQuery l’a éclipsé.

Encore aujourd’hui, beaucoup de gens qui sont « tombés dans Prototype » à l’époque continuent à l’utiliser, tout en connaissant aussi jQuery. Ils aiment Prototype pour son API claire, cohérente et élégante, ses nombreuses fonctions orientées algorithmes et programmation fonctionnelle (avec jQuery, il faut complémenter par Underscore.js, très fortement inspiré de Prototype, pour obtenir un équivalent).

Mais Prototype, aujourd’hui, c’est quelques jours par mois, voire par trimestre, du seul porteur du flambeau qui reste, le vaillant Andrew Dupont. Sa détermination sans faille me touche et m’émeut ; mais le projet n’en est pas moins dans un coma léger, parfois même profond.

Des utilisateurs fidèles

J’ai moi-même arrêté de travailler à Prototype il y a presque 4 ans. Jusqu’à cet été cependant, il restait ma bibliothèque de choix pour tous mes développements front.

Quand j’utilise jQuery, si j’apprécie la complétude de son offre Ajax/JSONP et certains aspects de son offre DOM, je peste contre les nombreux pièges inhérents au design de son API, pièges souvent silencieux et sournois à l’exécution.

Et j’ai, évidemment, toujours Underscore.js en complément, car je ne pourrais me passer d’un each raisonnable, de filter, inject, flatten, without et j’en passe.

De la gratitude

Alors oui, Prototype est pratiquement mort, malgré la persistence éminemment louable d’Andrew. Mais j’aimerais qu’on se rappelle que Prototype a été le premier. Sam a inventé ce positionnement de bibliothèque, a pondu des API dont l’influence se fait sentir partout, de ES5 à Underscore.js en passant par jQuery lui-même, que John a clairement dit avoir lancé « parce [qu’il] n’était pas totalement en phase avec Prototype ».

Autour de la 1.5, on a fait des prouesses pour les premiers outils de type $$, en implémentant l’intégralité des sélecteurs CSS3 à la fois en DOM Level 3 XPath et en parcours classique.

Prototype a permis des merveilles dès 2005, et a connu une sacrée gloire pendant plusieurs années.

Je lui dis un immense merci, et à mon sens, les web devs du monde entier, y compris ceux qui ne l’ont jamais utilisé, ont eux aussi cette dette de gratitude.

Et le web continue…

Ayant moi-même pondu quelques millions de lignes (littéralement, mais en Java ça n’est pas si impressionnant que ça) de Java et J2EE (ça ne s’appelait pas encore Java EE ; je me fadais les premières versions des EJB, JSP et servlets…), dans JBuilder, Eclipse, NetBeans et IDEA, je sais pourquoi j’ai fui cet univers et pourquoi JavaScript n’a strictement rien à voir.

Seulement voilà, le nommage prête à confusion, c’est un fait. Au mieux, on nous demande « c’est quoi la différence entre Java et JavaScript ? » Ce à quoi j’aime à répondre « la même qu’entre l’or et l’ordinateur » : à part le préfixe phonétique, la rapport est plutôt ténu…

Pour ceux qui aimeraient comprendre la petite histoire derrière la génèse de JavaScript et ce nommage foireux, permettez-moi de vous éclairer…

Le besoin d’origine et le cœur de la différence

Début 1995, Netscape domine le marché du web en général, fournissant tant des logiciels serveurs que le navigateur alors le plus populaire, Netscape Navigator. Ils viennent de lancer un partenariat avec Sun Microsystems pour exploiter leur nouveau langage et sa VM multi-plateforme, Java, tant au sein du navigateur (pour fournir une UI riche portable) que côté serveur (pour fournir le cœur d’applications accessibles via le web, au moyen d’un simple navigateur).

C’est une offre impressionnante, en concurrence directe avec Microsoft, qui commence à peine à accepter le fait que le web est là pour durer et qu’il constitue le prochain pivot technologique majeur.

Toutefois, Java est perçu par Sun et Netscape comme un langage de professionnels, peu adapté à une utilisation simple dans le cadre de pages web (on ne parle pas encore d’applis web, il faudra attendre 10 ans et l’avènement d’Ajax). Java est en quelque sorte le concurrent du Visual C++ de Microsoft, de ce point de vue. Il lui faut un langage compagnon plus simple d’approche, plus facile d’emploi pour les néophytes ou développeurs débutants, qui soit, si l’on veut, l’équivalent de Visual Basic. Facile à prendre en main, facile à imbriquer dans une page ou ailleurs.

C’est à Brendan Eich, gourou technique chez Netscape et futur CTO de Mozilla, qu’est revenue la tâche de créer ce langage « compagnon » de toutes pièces.

Ceci dit, on exige également que les deux soient bien différenciés, au sens où les développeurs potentiels doivent sentir que le nouveau langage est « dans le style Java » mais est moins puissant. Comme l’a expliqué Brendan dans une interview :

JS devait « ressembler à Java », mais en moins avancé, [il devait] être le petit frère simplet de Java, son partenaire-otage. Et par-dessus le marché, je n’avais que dix jours pour pondre ça, ou on se retrouverait avec un truc pire que JS.

JavaScript devait donc rester conscient des spécificités de la syntaxe de Java (JS 1.0 avait tous les mots-clés de Java réservés, et ses types standard copient souvent les conventions du JDK, par exemple autour de Math et Date), mais il devait aussi s’abstenir d’utiliser la syntaxe orientée-objet du langage, à une époque ou la POO (Programmation Orientée Objet) était encore considérée comme un sujet réservé aux professionnels…

Brendan ne voulait pas pondre un langage diminué, mais devait trouver des ruses pour y glisser assez de puissance sans que celle-ci soit immédiatement visible au profane. Le langage devait rester simple et léger en apparence, tout en ayant assez de sophistication pour que des développeurs avancés soient à même d’en tirer des applications puissantes.

Si les deux langages appartiennent à une famille syntaxique « de type C » (syntaxe des identifiants, accolades, opérateurs principaux, structures de contrôle…), ils ont des sémantiques extrêmement différentes. La philosophie de JavaScript est très fortement inspirée de langages objet ou fonctionnels « purs », au premier rang desquels Self et Scheme, mais aussi certains aspects de SmallTalk et LISP.

Java est un langage compilé, statique (chaque variable est typée explicitement) et doté d’un typage fort (le type déclaré contraint les valeurs de façon étroite, et aucune conversion implicite n’est mise en place), là où JavaScript est interprété et dynamique avec un typage plus léger (d’où la distinction entre == et ===, similaire à celle de PHP).

En Java, tout code existe à l’intérieur d’une classe. JavaScript ne l’exige pas.

Java, malgré près d’une décennie de débat stérile, n’a toujours pas de fonctions de premier ordre. JavaScript a des fonctions de premier ordre et, partant, des fonctions d’ordre supérieur.

Java utilise un modèle d’héritage « classique », mono-parent, basé sur l’héritage de classes. JavaScript est basé sur les prototypes et autorise plusieurs paradigmes de programmation, notamment les styles orienté-objet, impératif et fonctionnel (largement inspiré par Scheme).

Vous le voyez, les deux langages sont extrêmement différents, à un niveau pratique comme à un niveau fondamental, philosophique.

Les noms de départ

JavaScript était développé sous le nom de code Mocha, son nom officiel prévu étant LiveScript. C’était pourtant pas mal ce nom, vous ne trouvez pas ? Microsoft n’avait pas encore collé une connotation négative à « Live » à l’époque… Et d’ailleurs, dans les deux premières versions beta de Netscape Navigator 2.0, en septembre 1995, on trouve en effet LiveScript.

La décision marketing pourrie

Hélas, trois fois hélas, les marketeux ont voulu insister sur le rôle « collaboratif » de ce langage vis-à-vis de Java et ses applets, et tenter probablement de récupérer une partie du prestige issu du marketing de Sun autour de Java. Du coup, à partir de Netscape Navigator 2.0ß3, Brendan a dû le renommer JavaScript.

Et la confusion naquit.

Peu après, Netscape voulut, à juste titre, faire bénéficier JavaScript d’un processus formel de standardisation. IETF, ISO et le jeune W3C posaient chacun des problèmes distincts dans cette optique, de sorte qu’au final c’est l’ECMA (European Computer Manufacturers Association), un organisme de standardisation européen, qui a récupéré le bébé. Et on a vu apparaître la première édition du standard ECMA-262, pour le langage ECMAScript, qui est en pratique essentiellement utilisé en tant que JavaScript.

La 3ème édition (ES3) constitue le socle de la version la plus répandue/utilisée du langage (à peu près équivalente à JavaScript 1.5). La 4ème est morte-née, et la 5ème (ES5), désormais implémentée dans tous les navigateurs modernes, sert de socle aux applis web modernes et à JS côté serveur (avec Node.js notamment).

Ironie du sort

Ce qui à mon sens est assez amusant dans cette affaire, c’est que JavaScript est, finalement, disponible de base sur davantage de plates-formes et périphériques que Java, aujourd’hui. Même si l’explosion d’Android a fortement relancé le déploiement de Java, qui s’enorgueillit de « plusieurs milliards de périphériques installés » (comme en a longtemps témoigné la grande bannière Oracle/Sun à l’aéroport Charles de Gaulle terminal 1…), Java n’est pas tellement déployé sur d’autres plates-formes mobiles, et n’est pas non plus automatiquement présent sur toutes les plates-formes desktop.

Mais allez trouver un seul desktop, laptop, smartphone, tablette ou liseuse qui n’ait pas une runtime JavaScript installée—et s’en serve intensivement ! Dans certains cas, comme webOS et maintenant Firefox Mobile OS, JavaScript est au cœur-même de la plate-forme, constituant sa clé de voûte. Même sur iOS, Android ou les Blackberry récents, la tendance forte des mobile web apps repose très lourdement sur JavaScript. Petit à petit, les technologies collectivement appelées « HTML5 » remplacent ce pourquoi on avait encore recours aux applets ou, plus souvent, à Flash.

La couche serveur connaît elle aussi, depuis plus de 2 ans maintenant, une explosion de JavaScript comme langage de développement, avec des résultats impressionnants. La course à la performance des runtimes JavaScript (V8, cœur de Node.js, affiche des performances bluffantes), couplée au modèle de développement traditionnellement événementiel de JavaScript, qui permet d’assurer de fortes charges sans coût linéaire, y sont pour beaucoup.

Je souris en pensant que JavaScript, nommé ainsi parce qu’il essayait de « faire sérieux » et tirer parti des nues marketing auxquelles on portait Java, a déjà, je trouve, supplanté ce dernier en termes de présence sur les marchés qui comptent.

1
2
3

1234567890          // => 1234567890
999999999999999     // => 999999999999999
9999999999999999    // => 10000000000000000 -- WTF?!

Voyons ensemble la baleine qui se cache sous ce gravier…

Mais quelle magie obscure fait que 999999999999999 se comporte bien, mais pas 9999999999999999 ?

Comme dans de très nombreux langages, nous voilà pris au piège du standard IEEE-754, datant de 1985 (bientôt 30 ans…), qui gouverne la représentation 64-bit des nombres flottants. Vous retrouverez ce souci dans C, C++, Java, PHP, et pour autant que je sache, .NET (C#, VB, etc.) et ColdFusion… Mais uniquement sur les nombres flottants. Les nombres entiers 64-bit vont bien au-delà.

Seulement voilà, JavaScript ne différencie pas entiers et flottants. Le type Number est forcément flottant, c’est pourquoi en JavaScript 5 / 2 === 2.5, alors que les opérandes semblent « entiers ».

IEEE-754 prévoit une double précision (d’où le nom usuel du type associé dans de nombreux langages : double) de 15 chiffres. Au total (avant et après la virgule éventuelle). Dès qu’on dépasse ce nombre de chiffres, la représentation mémoire utilisée commence à faire des arrondis. Et plus on a de chiffres voulus, plus l’arrondi est brutal :

1

12345678901234567890 // => 12345678901234567000

Au passage, et pour le plaisir, notez que l’approximation n’a pas lieu que sur des très hautes valeurs. Si on tombe sur des valeurs qui ne sont pas représentables pile-poil par IEEE-754, on obtient des trucs comiques :

1
2

0.3         // => 0.3
0.1 + 0.2   // => 0.30000000000000004 !

Et oui, comme pour le statut truthy, la valeur seule ne suffit pas à garantir le bon fonctionnement : la façon d’y arriver est tout aussi importante.

Ici, il se trouve que 0.1 est représenté, en interne, par une valeur retranscrite en 0.10000000000000002. Et de même, 0.2 par 0.20000000000000002. Du coup, la somme aboutit à un résultat… étonnant !

Dans cet article, nous allons explorer ensemble quelles valeurs sont falsy, et donc lesquelles sont truthy, mais aussi l’impact que ça a sur de nombreux motifs de code courants, avec les pièges que ça peut poser.

Truthy et falsy

Dans un langage de programmation, on dit qu’une valeur est truthy si, considérée dans un contexte booléen (le plus souvent comme seul composant d’une condition, ou comme opérande d’un opérateur booléen tel que && ou ||), elle équivaut à true.

On dit que le protocole de conversion implicite de son type vers Boolean donne true. En JavaScript, ce protocole spécifique est régi, pour JavaScript « classique » (ECMAScript 3e édition) par la section 9.3 de la spécification (ECMA-262). Par complément, toute valeur dont la conversion ne donne pas true donne nécessairement false.

La spécification indique clairement que les types Undefined et Null équivalent toujours à false. Toute chaîne vide (longueur zéro) également. Côté nombres, les zéros (positif ou négatif) et NaN équivalent eux aussi à false. En revanche, n’importe quel autre objet (dont les tableaux et objets litéraux, même vides) équivaudra à true.

Ces règles semblent assez simples, même s’il peut être surprenant de voir que '' est équivalent à false (mais que new Boolean(false), étant un objet, est équivalent à true, un magnifique WTF). Toutefois, n’arrêtez pas là votre lecture, car dans divers cas « piégeux » les conversions implicites s’enchaînent sur une même valeur et donnent un résultat surprenant ! Nous avons vu les règles de base, mais attendez la suite…

Impact sur les motifs de code usuels

Examinons tour à tour les principaux cas où l’emploi booléen d’une valeur autre se présente dans du code JavaScript usuel.

Boucle numérique « façon C »

Une tentation courante consiste à reproduire les boucles numériques du C. Par exemple :

1
2
3
4

var count = 10;
while (count--) {
  // votre traitement ici
}

Ou encore :

1
2
3

for (var index = data.length - 1; index--; ) {
  // votre traitement ici
}

Pas de problème particulier sur cette boucle, en tout cas vis-à-vis de son équivalent C.

Le même risque potentiel existe, naturellement : si par mégarde le contenu de la boucle modifie le compteur, et que du coup celui-ci « saute » zéro ou est compensé dans son mouvement normal, cette boucle n’aura pas de fin (en C, elle finirait par un overflow/underflow, mais en JS, qui n’a que des nombres flottants, la fin est si loin qu’en pratique on ne patientera jamais assez longtemps, sans parler des bugs causés par le dépassement de limite).

Le piège est notamment là en JS, qui n’a pas de variables de blocs (sauf à disposer d’un JS garanti suffisamment récent pour pouvoir utiliser l’instruction let) :

1
2
3
4
5
6
7

// Attention, ce code n'a pas de fin !
for (var count = 10; count--; ) {
  console.log(count);
  for (var count = 0; count < 5; ++count) {
    console.log(count);
  }
}

Ahem…

Tester la présence d’un texte

Attention ici à la notion de « présence ». Si seul un texte absolument vide (longueur zéro) vous ennuie, pas de souci, c’est bien la sémantique d’origine :

1
2
3
4

// Supposons un champ <input type="text" id="firstName" value="">
if ($('#firstName').val()) {
  // Ce code ne sera pas déclenché
}

Mais si vous voulez un texte non-blank, c’est-à-dire contenant autre chose que du whitespace, il faudra préférer une regex (hein ?!) pour vérifier le contenu du texte :

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

// Supposons un champ <input type="text" id="firstName" value="   ">
if ($('#firstName').val()) {
  // Ce code SERA déclenché (à tort, a priori)
}

var BLANK_TEXT = /^\s*$/;
if (!BLANK_TEXT.test($('#firstName').val())) {
  // Ce code ne sera pas déclenché
}

// Alternativement :
var PRESENT_TEXT = /\S/;
if (PRESENT_TEXT.test($('#firstName').val())) {
  // Ce code ne sera pas déclenché
}

Tester la présence de nœuds du DOM

Si getElementById renvoie bien null s’il ne trouve pas l’élément d’id indiqué, l’immense majorité d’entre nous utilisons une bibliothèque JavaScript pour interagir avec le DOM. La plupart du temps, nous utilisons une API basée sur jQuery, qu’il s’agisse de jQuery lui-même, Zepto ou encore Ender. Du coup, ce que nous avons sous la main se comporte en fait comme un tableau, et n’est donc jamais équivalent false !

Voyez plutôt :

1
2
3

if ($('#idNotFound')) {
  // Ce code sera TOUJOURS exécuté !
}

C’est la raison pour laquelle on voit tant de code comme celui-ci :

1
2
3

if ($('#idNotFound').length) {
  // Si la longueur est non-nulle (élément trouvé) ce code sera exécuté
}

Paramètre doté d’une valeur par défaut

En CoffeeScript, c’est trivial à gérer, mais en JS pur c’est un peu plus compliqué. Tout dépend en fait des valeurs considérées comme valides pour l’argument.

Si aucune valeur falsy n’est valide, on est tranquille et on peut juste utiliser le || (OU logique) :

1
2
3
4
5

function earnMoney(luckyGuy, howMuch) {
  howMuch = howMuch || 10000;
  // Ou parfois : howMuch || howMuch = 10000; // Les goûts et les couleurs…
  console.log(luckyGuy + ' gagne ' + howMuch + '€');
}

Ici, on considère par exemple que howMuch à zéro, NaN, chaîne vide, et simplement non passé (undefined) ne constituerait pas une valeur acceptable. Il n’est donc pas possible d’appeler earnMoney avec un deuxième argument à zéro :

1
2
3

earnMoney('John')           // 'John gagne 10000€'
earnMoney('Nicolas', 1000)  // 'Nicolas gagne 1000€'
earnMoney('Yannick', 0);    // 'Yannick gagne 10000€' !

Lorsque des valeurs falsy sont acceptables, il vous appartient de tester plus efficacement. Par exemple, on pourrait refuser toute valeur négative ou nulle, et gérer évidemment le cas “argument manquant” :

1
2
3
4
5

function earnMoney(luckyGuy, howMuch) {
  if ('undefined' == typeof howMuch || +howMuch < 0)
    howMuch = 10000;
  console.log(luckyGuy + ' gagne ' + howMuch + '€');
}

(Notez au passage le recours à l’opérateur unaire préfixe +, qui force le protocole de conversion explicite ToNumber (conversion vers un nombre), et refusera notamment toute valeur textuelle ne constituant pas intégralement un nombre décimal valide. Cette technique est en ce sens supérieure à parseFloat.)

Ici on a bien le comportement souhaité :

1
2
3
4
5

earnMoney('John')            // 'John gagne 10000€'
earnMoney('Nicolas', 1000)   // 'Nicolas gagne 1000€'
earnMoney('Yannick', 0);     // 'Yannick gagne 0€'
earnMoney('Matthieu', -10);  // 'Matthieu gagne 10000€'
earnMoney('Marie', '10foo'); // 'Marie gagne 10000€'

Pièges des priorités de conversion

Les conversions implicites peuvent être problématiques. Elles sont déclenchées automatiquement sur toute condition mono-composant et opération binaire autre que === et !== (qui exigent une identité de type, en plus d’une identité de valeur, et sont recommandées par défaut pour toute comparaison, afin de réduire les risques).

Voyez plutôt :

1
2
3
4
5

console.log('  ' == false)     // true
if ('  ') console.log('mais…') // 'mais…'

console.log([] == false)     // true
if ([]) console.log('mais…') // 'mais…'

Voilà qui est fort étrange (et y’en a encore plein des comme ça). En fait, il ne s’agit pas ici uniquement de la conversion implicite de String ou Array en booléens, qui n’est utilisé que dans les if du code ci-dessus. Il s’agit aussi de la spécification de l’opérateur ==, telle que décrite au paragraphe 11.9.3 de ECMA-262 (3ème édition), la spécification de JavaScript. Déroulons les parties pertinentes de l’algo utilisé par le moteur JS pour le premier cas, ' ' == false :

1. On a affaire à un non-booléen comparé à un booléen : on compare ' ' à ToNumber(false)
2. La conversion implicite numérique d’un booléen vaut +0 (0, quoi…) pour false, on a donc ' ' == 0
3. On compare une String avec un Number : on compare ToNumber(' ') à 0
4. La conversion implicite numérique d’une chaîne de caractère constitué uniquement de whitespace vaut (section 9.3.1) 0, on compare donc 0 == 0, ce qui vaut évidemment true.

En revanche, dans le cas du if, on applique immédiatement ToBoolean(' '), et comme la chaîne n’est pas vide, on obtient true.

Subtil ! Et, oui, un peu foireux côté spécification…

Pour le second cas, [] == false, on obtient le même type de déroulé, si ce n’est qu’à l’étape 3 on atteint Object (Array est un type descendant) avec un Number, ce qui déclenche ToPrimitive([]), décrit à la section 9.1. Celle-ci nous dit qu’on utilise alors la propriété système [[DefaultValue]] de l’objet, telle que décrite à la section 8.6.2.6 (remarquez combien ECMA-262 est une spécification pour les implémenteurs, et non pour les développeurs, et comme on s’y emmêle les pieds à coups de références croisées comme dans un code juridique). Les renvois continuent, jusqu’à ce qu’on se rende compte qu’on aboutit à une conversion numérique aboutissant, faute d’élément unique exploitable dans le tableau, à zéro.

Bref, faites attention lorsque vous exploitez une valeur non booléenne comme booléenne : il n’y a pas que la conversion implicite du type d’origine, mais aussi, pour une expression avec opérateurs, les algorithmes de conversion d’opérande définis pour ces opérateurs. Et les deux peuvent, en effet, se contredire.

• De nouveaux ateliers
• (Beaucoup) plus de dates et un lieu de formation au top
• Plus d’articles didactiques sur le site
• Une nouvelle plate-forme intégrée pour présenter les formations, gérer les inscriptions, permettre les évaluations et commentaires, accéder aux ressources pédagogiques, demander des conventions de formation, etc.

De nouveaux ateliers

Comme annoncé il y a quelques semaines sur Twitter, l’automne-hiver 2012 voit l’apparition de 3 nouveaux ateliers au catalogue JS Attitude :

• JS Total est une énorme tuerie qui combine, sur 4 jours consécutifs, tous les savoir-faire des autres formations, dans un contexte plus intégré : du langage lui-même à l’optimisation du déploiement et des performances en passant par le MVC, les Web Sockets, les tests automatisés et la documentation. La première session aura lieu du 11 au 14 décembre.
• CoffeeScript est un atelier de formation d’une journée permettant de découvrir cette extraordinaire façon de développer du JavaScript qualitatif et performant. Vous pourrez le tester dès le 18 décembre.
• Coffee Guru combine l’atelier CoffeeScript et JS Guru v3, mais ce dernier est allongé sur 2 jours au lieu d’un, et 100% en CoffeeScript, pour permettre aux stagiaires de passer davantage de temps en exercice personnel et leur donner l’occasion de s’approprier ainsi davantage l’ensemble des savoirs dispensés. Première session de 3 jours du 19 au 21 décembre prochains.

D’autres ateliers devraient ouvrir sur le premier trimestre 2013, et vous en verrez un aperçu dans notre catalogue. En attendant, nous vous invitons à regarder le détail des pages des ateliers pour découvrir les programmes détaillées, le lieu de formation, les tarifs et dates, etc.

Nouveau planning, nouvel endroit !

Historiquement, les sessions Attitude inter-entreprises se sont toujours tenues le samedi, presque exclusivement dans les locaux de Clever Age Paris, boulevard des Capucines, à deux pas d’Opera. Nous tenons d’ailleurs à les remercier encore une fois chaleureusement pour ce gentleman’s agreement qui aura duré plus de 2 ans et sans lequel les formations Attitude n’auraient peut-être pas connu le succès qui est le leur aujourd’hui.

Toutefois, cette contrainte de planning (samedi seulement, une journée maximum) posait problème à de nombreux stagiaires potentiels, et limitait la gamme des ateliers proposables.

La dernière session du samedi, chez Clever Age, se tiendra le 27/10 pour un JS Guru. Après cela, toutes les sessions seront en semaine dans notre nouveau lieu. Jusqu’à nouvel ordre, elles se tiendront entre le mardi et le vendredi.

La barre latérale du site (ou sur mobile, le bas de page) listent à tout moment l’ensemble des dates prévues, avec le cas échéant un indicateur de places restantes (s’il en reste 4 ou moins). À ce jour, les dates suivantes sont proposées :

1. JS Guru samedi 27/10
2. JS Puissant jeudi 22/11 session retirée avant inscriptions en raison d’un fort volume d’intra
3. JS Guru jeudi 29/11 session retirée avant inscriptions en raison d’un fort volume d’intra
4. JS Puissant vendredi 07/12
5. JS Total du mardi 11 au vendredi 14/12
6. CoffeeScript mardi 18/12
7. Coffee Guru du mercredi 19 au vendredi 21/12

Aucune session n’est prévue sur la dernière semaine de décembre ; passez donc les fêtes avec proches, que diable !

Par ailleurs, à compter du 20/11/2012, nous serons également beaucoup plus disponibles pour des formations intra-entreprises et/ou sur-mesure. Là aussi, la sidebar et une page dédiée vous informent et vous permettent de nous contacter sur ce sujet.

Parlons à présent du nouvel endroit dans lequel auront lieu les formations Attitude.

Nous avons longuement cherché un endroit qui corresponde à nos exigences et à l’esprit des formations : décontracté, agréable et professionnel. Nous avons donc été emballés en découvrant et visitant l’espace La Rochefoucauld du Groupe Formeret.

Le Groupe Formeret ne fait qu’une chose et le fait manifestement très bien : héberger des formations, séminaires, examens, etc. Leurs 4 lieux sont impeccables, parfaitement accessibles à tous, conviviaux et lumineux. À leur rencontre, on sent tout de suite leur volonté de bien faire et de fournir un service d’excellente qualité. Nous espérons avoir trouvé en eux un partenaire de confiance sur la durée.

Nous avons choisi en priorité l’espace La Rochefoucauld en raison de sa situation géographique (Notre-Dame de Lorette / Saint-Georges, presque aussi central qu’Opéra) mais aussi du cachet du lieu (très calme, entouré de verdure, avec une vue imprenable sur le Sacré-Cœur) et de sa taille, qui permet d’éviter un effet « grands bureaux ».

La formation se déroule dans une salle privative climatisée, lumineuse, fonctionnelle et très confortable. L’ensemble des locaux sont facilement accessibles en transports en commun et classés ERP, notamment accessibles aux Personnes à Mobilité Réduite.

Espace La Rochefoucauld
11 rue de La Rochefoucauld
75009 Paris

Situé en plein cœur de Paris, tout près de la Gare Saint-Lazare et d’Opera, il est accessible via pas moins de 6 lignes de métro, 2 lignes de RER et 7 lignes de bus :

• Métro : Saint-Georges, Trinité (ligne 12), St-Lazare (lignes 3, 9, 12, 13 et 14), Chaussée d’Antin (lignes 7 et 9)
• RER : Haussman Saint-Lazare (ligne E), Auber (ligne A)
• Bus : Saint-Georges (67, 74), La Bruyere (74), Trinité (26, 32, 43, 68, 81)

On trouve également nombre de parkings alentour.

Chaque stagiaire amène son propre poste de travail ou ordinateur portable.

L’accès internet est assuré par une connexion fibre très haut débit. La salle fournit un accès Wi-Fi ainsi que des connexions RJ45 pour les postes qui le nécessiteraient.

Plus d’articles didactiques

Jusqu’à présent, le manque de temps ne nous a pas permis de donner au site JS Attitude l’envergure pédagogique et didactique que nous souhaitions. Des dizaines de sujets d’articles et de didacticiels attendent depuis de nombreux mois d’être rédigés et publiés. Les articles du site et la timeline Twitter se résumaient pour l’essentiel à des annonces d’atelier et du marketing.

Si le marketing ne disparaîtra pas tout-à-coup du flux (pour le moment, Twitter et le bouche-à-oreille restent nos seuls canaux de communication et de marketing), les articles d’annonce, eux, n’auront plus cours : les pages détaillées des ateliers existent et contiendront toujours la liste des prochaines dates ; leurs URLs ne changeront pas. Et la sidebar du site reprend ces informations.

En revanche, nous allons prendre de plus en plus de temps pour produire et publier des articles, didacticiels et suggestions de veille technologique, sur un rythme régulier et, nous l’espérons, assez fréquent. Nous espérons qu’ainsi, vous trouverez le site toujours plus intéressant et utile.

Bientôt une nouvelle plate-forme intégrée

Il n’est plus possible pour le moment de vous inscrire directement en ligne, en payant par carte bancaire ou PayPal. Nous travaillons à l’aboutissement d’un projet interne de plate-forme qui va regrouper l’ensemble des services en ligne dont les formations Attitude ont besoin : présentation, suivi des places disponibles, inscription ou demande de convention en ligne, attestations de présence, factures, évaluations par les stagiaires, accès aux ressources pédagogiques et forums de discussion entre les stagiaires passés et les formateurs, etc.

Les sites dédiés (js-attitude.fr, git-attitude.fr, etc.) se concentreront alors sur les contenus didactiques, et recroiseront diverses infos (dont le planning des sessions) avec la plate-forme.

En attendant, vous pouvez naturellement toujours nous faire une demande de convention via le formulaire habituel.

En résumé…

Dès mi-novembre, Attitude passe la 5ème ! Nous espérons vous retrouver nombreux à nos sessions, et que le travail et la passion intenses que nous mettons dans la conception et la tenue de nos ateliers sauront vous séduire.

Parce que nous anticipons des articles de plus en plus riche en codes sources, parce que nous souhaitons enrichir la discussion autour des commentaires et des réseaux sociaux, et parce que nous trouvons le look par défaut beaucoup plus propre que ce qu’on sur le site en place, nous avons passé JS Attitude sur Octopress.

Vous trouverez déjà un nouvel article, plutôt long, de nature didactique (une catégorie que nous avons bien l’intention d’enrichir régulièrement désormais) : Enfin maîtriser les expressions rationnelles. Ce sujet, qui nous tient à cœur, n’avait pas pour autant sa place dans JS Puissant, aussi il figure désormais sur le site, libérant de la place dans l’atelier pour approfondir d’autres sujets plus importants (par exemple la programmation fonctionnelle et les prototypes).

Le catalogue 2012–2013, lui aussi, est à l’honneur, au travers de la nouvelle page Tout sur les ateliers et des pages détaillées pour nos formations existantes (mais parfois remaniées) et nouvelles (pas moins de 3 d’ici fin 2012 !). Un article d’annonce spécifique est dans les fourneaux.

Vous trouverez d’ailleurs une liste à jour des dates planifiées des ateliers JS Attitude dans la barre latérale (ou inférieure, sur des affichages étroits), ainsi qu’en bas de chaque page atelier du catalogue. À partir de la mi-novembre 2012, vous aurez jusqu’à 8 jours de formation proposés par mois !

Nous espérons que le nouveau JS Attitude vous plaira. Comme toujours, n’hésitez pas à échanger avec nous via les commentaires en bas de chaque page. À très vite pour des articles et formations du tonnerre !

C’est un sujet qui me tient véritablement à cœur, pour les raisons que je vais développer dans les deux premiers titres. Mais on m’a quelquefois fait remonter, très justement, qu’une telle couverture, au sein d’un atelier de 8h, est tout-à-fait hors de proportion, et que le temps libéré pourrait être utilement mis à profit en entrant plus dans le détail d’autres aspects (programmation fonctionnelle, structuration de code…).

Afin de ne pas simplement cesser de transmettre ces connaissances et de « convertir » les gens au bon usage des expressions rationnelles, j’ai donc opté pour l’approche inverse : sortir ce contenu des formations pour en faire un contenu librement accessible sur le site de JS Attitude !

Qui sait ? Peut-être cet article, s’il est suffisamment bien fichu, deviendra-t-il, à son petit niveau, une sorte de référence francophone sur ce sujet, comme le sont désormais des articles de Git Attitude sur les clés SSH ou l’installation de Gitosis…

Le croque-mitaine

Traditionnellement, les expressions rationnelles ne sont pas enseignées. Il est déjà assez difficile de trouver un prof de BTS ou DUT capable de faire véritablement du Java, sans même parler de Python, Ruby ou JavaScript, pour espérer avoir carrément des cours décents d’expressions rationnelles.

Popularisées par Perl, les expressions rationnelles débarquent en général au travers d’un morceau de code parfaitement abscons, comme le dégorgement inattendu d’un fragment de fichier binaire au beau milieu du code source. Et de fait, quel développeur, pas forcément junior mais globalement sain d’esprit, n’aurait pas le cœur au bord des lèvres en tombant tout à coup sur ce genre de chose :

1

if (expr.match(/\w+\[([\w-]+)(?:[*~^$]?=(['"])?(.+?)\1\]/))

C’est vrai, quoi, comprenez-les. Les pauvres, personne ne les a prévenus, sinon ils n’auraient pas choisi le pâté de tripes à midi, vous pensez bien, c’était trop risqué.

Faute d’enseignement, faute de rationalité justement, faute de démystification utile, les expressions rationnelles restent à la périphérie de nos regards et de notre conscience, les banshees du développement, on les garde soigneusement à distance de peur qu’en y touchant elles ne nous attrapent tout entiers et nous volent ce qui nous reste de raison, tels de petits Cthulhus tout de symboles vêtus.

Le bon outil pour manipuler du texte

Naturellement, il n’en est rien, ne prêtez pas attention à cette porte qui claque quelque part dans l’asile d’Arkham. Les regex restent un outil extrêmement efficace pour extraire rapidement des éléments spécifiques d’un contenu textuel. Par exemple, repérer certaines balises dans du HTML ; trouver les lettres en double dans un texte ; capitaliser un texte (mettre ses initiales en majuscules et le reste en minuscules) ; détecter qu’un texte est bien une adresse e-mail (ou IP, ou URL…) valide ; etc.

Il est bien sûr possible d’écrire des algorithmes manuels pour tous ces usages, mais ceux-ci présentent deux inconvénients majeurs vis-à-vis des expressions rationnelles équivalentes :

• Ils sont souvent largement plus verbeux (jusqu’à plusieurs centaines de lignes de code), et donc sujets à potentiellement bien davantage de bugs, notamment des erreurs de bornes (les erreurs +1/-1, ou fencepost errors) et de conditions de boucle.
• Ils sont en général significativement plus lents que leur équivalent à base d’expressions rationnelles.

Vous me rétorquerez peut-être qu’ils sont bien plus lisibles. C’est un argument aussi classique que fallacieux.

À part les cas triviaux d’analyse de texte (par exemple, en compter les consonnes), ce n’est pas vrai : tout traitement un tant soit peu avancé requiert automatiquement un volume non négligeable de code, avec ses variables, conditions, etc. La lisibilité se dégrade rapidement, ou à défaut, on obtient du code lisible, mais volumineux, dont il faut en outre comprendre l’algorithme pour en saisir l’objectif. Même si on se cantonne aux cas où le code alternatif est court, l’expression rationnelle équivalente est, elle, triviale, et ne devrait donc pas poser de souci de lisibilité.

Qui plus est, la lisibilité d’une expression rationnelle est perçue traditionnellement comme mauvaise pour deux raisons : d’une part, nombre de gens écrivent des expressions balourdes, pataudes, ne tirant pas le meilleur parti de la syntaxe qu’elles alourdissent inutilement. D‘autre part, cette syntaxe, bien que grammaticalement assez simple, est effectivement assez peu intuitive : la majorité des développeurs ont donc connu le syndrome du « WTF?! » lors de leurs premières rencontre avec de telles expressions, ce qui entraîne un préjugé.

Enfin, nombre de personnes n’utilisent pas (où n’ont pas à disposition, comme c’est hélas le cas en JavaScript natif) le drapeau de syntaxe x, qui permet de découper et commenter une expression rationnelle lors de sa déclaration, ce qui accomplit des miracles en termes de lisibilité. Nous y reviendrons en fin d’article avec la bibliothèque XRegExp.

Un mot de vocabulaire

Expression rationnelle ou régulière ?

La terminologie anglaise ne connaît que regular expression, l’adjectif insistant sur le fait que, comme pour l’algèbre relationnelle, les expressions régulières sont basées sur des principes mathématiques déterministes et que la syntaxe est donc sans ambiguïté (si si !). En France, sans doute à la faveur de traductions initiales ayant pris quelques libertés, on s’est vite retrouvé avec les deux locutions expression régulière et expression rationnelle. On rencontre l’une à peu près aussi souvent que l’autre. J’ai personnellement pris le parti de la seconde, car je trouve que le rationnelle met davantage en avant ce principe de conception ; employez l’un ou l’autre comme bon vous semble, mais soyez juste cohérent avec vous-même !

Dans les deux cas, c’est tout de même assez long, aussi utilise-t-on la majeure partie du temps l’abréviation regex, en anglais comme en français, qui a en outre le mérite d’éviter le débat précédent. Dans le reste de cet article, j’emploierai cette abréviation dans un souci de concision.

« Reguex » ou « Redjex » ?

C’est la question suivante, posée par ceux qui se soucient de leur prononciation (et je les en félicite). Bien que l’origine du reg (regular) incite à l’utilisation d’un g dur (« reguex »), la prononciation anglaise usuelle ne s’intéresse qu’à l’abréviation elle-même, et comme le g est doux devant les e et les i, on prononce effectivement « redjex ».

Les exemples classiques

Afin d’essayer de bien illustrer tout l’intérêt que peut représenter l’emploi des regex dans son code, en voici quelques-unes assez classiques. Le lecteur qui pinaille trouvera naturellement tout un tas de contre-exemples, mais le but n’est pas ici de recenser les solutions en béton armé, qui doivent gérer une telle pléthore de cas qu’elles sont en effet complexes (bien moins que les algorithmes associés, néanmoins). Il s’agit de montrer des cas pas trop ahurissants ! On n’aura par ailleurs recours qu’aux syntaxes gérées nativement par JavaScript (pas de groupes nommés, notamment).

• [0-9a-f]+ — Nombre entier hexadécimal
• (['"]).*?\1 — Chaîne de caractères (guillemets simples ou doubles, mais cohérents entre eux ; pas d’échappement)
• [\w.-]+@[\w-]+\.\w{3,6} — E-mail (basique)
• [\w-]+(\.[\w-]+){1,} — FQDN (nom de domaine, hors IRI)
• <[^>]+> — Balise XML (ouvrante ou fermante)
• \&(lt|gt|apos|quot|amp); — Échappement XML (les cinq entités obligatoires)
• (?:\d{1,3}\.){3}\d{1,3} — IP (basique)
• (?:(?:1?\d{1,2}|2[0-4]\d|25[0-5])\.){3}(?:1?\d{1,2}|2[0-4]\d|25[0-5]) — IP (exact : contrôle des valeurs)
• [a-z]+://[^:/]+(?::\d+)?(?:/[^?]+)?(?:\?[^#]+)?(?:#.+)? — URL (syntaxes des composants un peu laxistes…)

Déconstruire une expression rationnelle

Devant le foutoir (ben si, des fois, le foutoir !) que peut représenter une regex au premier abord, l’important est de savoir la déconstruire. Et là, c’est un peu comme les poupées russes : on procède de l’extérieur vers l’intérieur. La clé est aussi de savoir bien repérer les classes, groupes et leurs éventuelles imbrications, pour délimiter ainsi notre analyse.

Par exemple, prenons la première, [0-9a-f]+. On y repère une classe, c’est-à-dire une série de possibilités pour un unique caractère : [0-9a-f], qui est assez facile à décoder : de 0 à 9 et de a à f, donc un caractère hexadécimal. Et le quantificateur + vient indiquer qu’on s’attend à trouver ça au moins une fois.

Plus compliqué : (?:\d{1,3}\.){3}\d{1,3}. Là, on doit repérer tout de suite le groupe (non capturant en l’occurrence, mais passons) (?:\d{1,3}\.), et noter qu’il est quantifié 3 fois. On va même remarquer rapidement que la suite de l’expression est en fait une redite du contenu du groupe, au point final près. Les regex n’ont hélas pas de syntaxe pour dire “schéma X, N fois, séparé par schéma Y” : on se retrouve le plus souvent à dire “X + Y, N fois, puis X une dernière fois”. Sans pouvoir nommer les groupes, ça fait du doublon, comme ici. Et le contenu répété, \d{1,3}, est assez simple : « un chiffre décimal, 1 à 3 fois ».

Et ainsi de suite, en découpant le problème originel de plus en plus, pour se concentrer sur des fragments assez petits pour être analysés directement sans péter un câble. Mais croyez-moi, avec un peu de pratique, c’est beaucoup plus facile qu’il n’y paraît.

Construire une expression rationnelle

Pour construire une regex, on fait l’inverse : on part des petits composants, et on… compose, au fur et à mesure. Plus on a bien découpé à la base, plus la construction se fera naturellement, et moins on aura de répétition.

Supposons par exemple que vous souhaitiez créer une expression de validation d’un login, qui aurait les contraintes suivantes : uniquement des caractères alphanumériques ASCII, à raison d’un minimum de 6 et d’un maximum de 12. Comment s’y prend-on ?

Déjà, tous les caractères ont la même contrainte, ce qui est bon signe : ça va nous éviter de multiplier les composants. On doit donc d’abord exprimer la contrainte sur un caractère, sous forme d’une série de valeurs possibles. C’est là le rôle des classes, on écrit donc [a-z0-9] pour lister les caractères et chiffres ASCII. Il ne nous reste plus qu’à quantifier ça, entre 6 et 12 occurrences : [a-z0-9]{6,12}.

Apprivoiser les expressions rationnelles pas à pas

La syntaxe des expressions rationnelles a finalement assez peu d’éléments potentiels. Et ce d’autant plus que JavaScript ne gère pas nativement certaines extensions intéressantes, comme le drapeau x ou les groupes nommés. Nous allons examiner ces possibilités tranquillement, une par une, dans la suite de cet article.

Syntaxe des regex litérales en JavaScript

En JavaScript, vous avez deux manières d’obtenir une regex utilisable : en l’écrivant directement dans le code, de façon statique, sous forme d’un litéral. Ou en utilisant une construction d’objet explicite, avec la syntaxe new RegExp.

Dans la pratique, cette deuxième syntaxe n’a d’intérêt que si vous devez construire une regex dynamiquement sur la base de contenus que vous ne connaissez pas encore en écrivant le code (par exemple, une saisie utilisateur). Dans tous les autres cas, préférez la syntaxe litérale, plus concise.

Une regex litérale en JavaScript, c’est trois choses : les délimiteurs, l’expression elle-même, et les drapeaux de contrôle.

Délimiteurs

En JavaScript, on n’a pas le choix : une regex litérale est forcément encadrée par des slashes (/). Du coup, tout slash dans l’expression devra être échappé (\/), ce qui peut vite donner des trucs cocasses (/^https?:\/\//)…

Drapeaux (flags)

Les drapeaux de contrôle se placent après le slash de terminaison. JavaScript en reconnaît trois :

• i est très pratique et fréquent : Insensible à la casse. Permet d’éviter la galère de devoir spécifier tous nos caractères possibles en minuscules ET en majuscules, lorsqu’on accepte les deux…
• g rend la regex Globale : au lieu de se concentrer sur la première correspondance du texte, elle pourra agir sur toutes les correspondances. Change fondamentalement les comportements de recherche et de remplacement…
• m est souvent mal compris. Lui qui signifie Multi-lignes ne veut pas dire que notre regex va automatiquement marcher sur des correspondances à plusieurs lignes (et tout particulièrement, il ne permet pas au caractère générique total, ., de sauter les lignes), juste que les ancres (indications de position) ^ et $ correspondront aux bords de ligne, et non aux bords du texte total. Ce drapeau sert plus rarement.

Ainsi par exemple, une regex de nombre hexadécimal sera plus probablement /[0-9a-f]/i, car dans la plupart des langages, la casse des lettres est sans importance pour les litéraux numériques.

Représenter un seul caractère de correspondance

Armés de ces connaissances de base sur la structure extérieure d’une regex, voyons l’intérieur. Une regex, fondamentalement, sert à chercher une correspondance dans un texte (voire à vérifier la correspondance du texte dans son ensemble). L’unité de base de ce travail, c’est le caractère. Quelles contraintes peut-on donc exprimer sur un seul caractère, pierre angulaire de la suite ?

Caractères litéraux (non spéciaux)

Tout d’abord, on peut exiger qu’il s’agisse d’un caractère précis. Lui et pas un autre. Il suffit alors d’utiliser le caractère directement, comme un litéral. Par exemple, a ne peut correspondre qu’au caractère A minuscule latin (code numérique 97).

Si votre caractère joue un rôle spécial dans les regex, il faudra l’échapper (sauf si vous êtes au sein d’une classe, ce qui la plupart du temps vous en dispense automatiquement, sympa). Par exemple, /?[a-z]=/i ne va pas faire correspondre un texte avec un point d’interrogation suivi d’une lettre ASCII suivi du signe égale : le point d’interrogation est un quantificateur, comme on le verra plus loin, et s’attend donc même à avoir un contenu qui le précède : cette regex est invalide et votre interpréteur JS considérera ce morceau de code comme invalide. Il faudra employer /\?[a-z]=/i pour obtenir le résultat souhaité.

Classes explicites

Si on se contentait de comparer des caractères précis, on n’aurait pas besoin des regex : une bête comparaison de chaîne suffirait !

Afin d’exprimer une série de possibilités pour un caractère unique dans le texte analysé, on utilise des classes. Elles consistent à lister les caractères possibles, entre deux crochets. Par exemple, pour représenter les voyelles minuscules latines :

[aeiouy]

Évidemment, si on doit se farcir toutes les possibilités manuellement, ça va vite faire longuet… Lorsque les caractères possibles sont adjacents dans la table de caractères, on peut donc juste séparer les limites de la plage voulue par un tiret :

[a-z]

Et on peut naturellement combiner caractères explicites et plages, comme ci-dessous pour les chiffres hexadécimaux par exemple :

[a-f0-9]

Il peut par ailleurs arriver qu’on souhaite exprimer non pas tous les caractères autorisés mais plutôt, par concision, tous les caractères interdits. On parle alors de classe négative, qui doit commencer par un circonflexe. Ainsi, pour interdire les chiffres arabes par exemple, mais autoriser tout le reste, on dirait ceci :

[^0-9]

Le sens spécial qu’ont le crochet fermant, le tiret et le circonflexe à l’intérieur d’une définition de classe obligent soit à les échapper (en les précédant d’un backslash), soit, pour le tiret, à le placer en bord de classe, afin de lever l’ambiguïté (s’il n’a pas de caractère des deux côtés, il n’indique pas un intervalle).

Classes prédéfinies

Certaines séries sont suffisamment communes pour disposer de syntaxes raccourcies. Celles-ci se présentent sous forme d’un backslash suivi d’une lettre. Les trois lettre gérées par JavaScript sont :

• d pour digit, qui regroupe les chiffres arabes.
• w pour word, qui regroupe les lettres latines ASCII, les chiffres arabes et le tiret de soulignement (underscore)
• s pour space, qui regroupe les espacements usuels ASCII (espace, tabulations, saut de ligne, saut de page)

Si la lettre est minuscule, on a une classe positive (seuls ces caractères-là). Si elle est majuscule, on a une classe négative (tout sauf ces caractères-là). Ainsi, \d équivaut à [0-9] et \W équivaut à [^a-z0-9_].

ASCII vs. Unicode

Il est dommage que JavaScript ne gère pas mieux les jeux de caractères « réels », ceux employés par les langues. Ainsi, \w ignore les signes diacritiques (accents, cédilles, etc.) et d’une manière générale toutes les lettres non latines (grecques, allemandes, asiatiques…). Dans le même esprit, \s ignore l’espace insécable, aussi fréquente soit-elle.

Nous verrons en fin d’article qu’une petite bibliothèque JavaScript, XRegExp, étend considérablement les possibilités des regex en JavaScript, si vous avez ce type de besoin.

Combinaisons de classes

Il est possible de combiner des classes prédéfinies au sein d’une classe explicite, éventuellement avec d’autres caractères spécifiques, par exemple comme ceci :

[\wéèêëàâäîïôöûüç\s\u00a0]

On trouve ici les alphanumériques latin/arabe, le soulignement, les principales lettres françaises à signe diacritique, les espacements ASCII et l’espace insécable. JavaScript nous autorise en effet à utiliser la syntaxe de code litéral Unicode \uxxxx. On a ici le code 160 (a0 en hexadécimal), qui est l’espace insécable dans la table Unicode. C’est une syntaxe qu’on retrouve également dans CSS.

La classe générique : point

Une classe particulière est le Any char : . (point). Elle représente en théorie n’importe quel caractère. Dans la pratique, elle est limitée par l’activation (ou pas) d’un flag de comportement indiquant si elle comprend aussi les sauts de ligne ou non. Un tel flag n’existe pas dans les regex JavaScript standard, et le point ne correspond jamais à un saut de ligne, même avec le mode multi-ligne (contrairement à d’autres moteurs de regex, comme par exemple celui de Ruby). Là encore, XRegExp offre une amélioration.

En tous les cas, il faut faire attention au risque d’employer un point litéral sans réfléchir, car le point des regex voudra dire « n’importe quel caractère » ! Pensez alors à l’échapper avec un backslash.

Représenter plusieurs caractères successifs

Jusqu’à présent, nous nous sommes concentrés sur l’établissement d’un critère pour un caractère. Mais dans une analyse de texte, c’est une séquence de caractères que nous allons examiner !

Parties fixes

Le plus simple consiste à utiliser, à la suite, les descriptifs de motif pour chaque caractère du texte à analyser. Par exemple, si vous voulez juste une lettre suivie d’un chiffre, vous direz sans doute :

[a-z]\d

Toutefois, la plupart du temps vous souhaitez aussi indiquer qu’un motif donné est acceptable pour davantage qu’un seul caractère : peut-être 2, 10, au moins 20, maximum 15, un ou plus, ou un nombre quelconque (y compris aucun)… C’est le rôle des quantificateurs.

Quantificateurs

Un quantificateur est une syntaxe spéciale qui, employée derrière un élément de la regex, modifie sa quantité potentielle. À la base, tout composant de la regex est attendu exactement une fois. On peut toutefois le faire suivre des syntaxes de quantification que voici :

• ? signifie « zéro ou un », ce qui revient à dire « optionnel ».
• + signifie « au moins un ».
• * signifie « un nombre quelconque de fois » (y compris zéro).

Il est aussi possible d’utiliser des bornes précises, au moyen d’une syntaxe un peu plus longue, encadrée par des accolades (curly braces) :

• {4} pour « exactement 4 fois ».
• {4,12} pour « entre 4 et 12 fois ».
• {4,} pour « au moins 4 fois ».

La syntaxe {,4} n’existe pas, pour la simple raison qu’on obtient le même résultat avec {0,4}.

Quantificateurs réticents

Les quantificateurs vus à l’instant sont tous qualifiés de gourmand (greedy quantifiers), au sens où ils tenteront systématiquement d’obtenir la plus grande correspondance possible. Ce n’est pas toujours ce qu’on veut. Prenons par exemple le texte analysé suivant :

1

<p><a href="#deuze">Et yop la deuze</a> - <a href="#quarte">Et yop la quarte</a></p>

Imaginons maintenant que nous voulons récupérer les liens. Une regex naïve serait /<a.*>.+<\/a>/g. Mais ça va nous donner un unique résultat : "<a href="#deuze">Et yop la deuze</a> - <a href="#quarte">Et yop la quarte</a>". Ah. Flûte. Le souci ici vient du fait qu’on utilise des quantificateurs gourmands. On pourrait bien sûr remplacer le premier par [^>]* histoire d’être sûrs de s’arrêter en fin de balise ouvrante, mais ça ne marche pas pour le deuxième, car si on faisait …>[^<]+</a>, on s’arrêterait dès qu’un lien contient des balises…

On peut plutôt recourir à des versions réticentes.

Il suffit de rajouter un ? à la fin du quantificateur gourmand usuel :

1

/<a.*?>.+?<\/a>/g

Et là, on obtient bien deux résultats, un par lien. Les quantificateurs vont s’arrêter au premier chevron fermant rencontré et au premier </a> rencontré.

Alternative entre deux séquences

Pour indiquer une alternative entre caractères, on utilise généralement une classe. Par exemple, [arz] signifie « a, ou r, ou z ». Mais comment faire pour des séquences ? On les sépare par un pipe (|).

Ainsi, hello|world signifie « hello ou world ». Et [1-9][0-9]*|0x[0-9a-f]+ signifie « un litéral nombre décimal (chiffre de 1 à 9 suivi éventuellement de chiffres décimaux) ou un litéral nombre hexadécimal (0 puis x puis un nombre quelconque non nul de chiffres hexadécimaux) ».

Attention cependant, il peut y avoir un piège quant à la portée de l’alternative : par défaut, elle s’applique à tout ce qui l’entoure ! C’est vite un souci, mais nous allons voir comment le résoudre dans un instant.

Groupes

Il est possible de rassembler des fragments de vos regex en groupes. Il y a plusieurs raisons de faire cela : pour quantifier plus qu’un simple caractère (mais carrément toute une séquence), pour limiter une alternative, ou pour obtenir comme résultat, en plus de la correspondance globale, des segments précis de celle-ci.

La syntaxe fondamentale des groupes est toujours la même : on entoure un groupe par des parenthèses : ( et ).

Grouper pour quantifier une séquence de caractères

Imaginons que vous souhaitiez faire une regex toute bête : « au moins deux mots ». Au sens « au moins deux séries de non-espacements », par exemple. La séquence « série de non-espacements » est assez facile : \S+ (majuscule). Et les mots seraient séparés par, justement, des séries d’espacements : \s+ (minuscule).

Pour dire « deux mots », on pourrait donc faire \S+\s+\S+. Hmmmm. Mais pour dire « au moins deux mots » ? On fait comment. Comme souvent lorsqu’il s’agit de séquences alternées (motifs X séparés par motif Y), on doit la représenter en deux parties :

1. Motif X
2. Motif Y puis Motif X, le tout un certain nombre de fois (le tout quantifié, quoi).

Ici, vu qu’on veut « au moins 2 mots », le quantificateur de cette deuxième partie serait « au moins 1 fois », donc le +. Mais on ne peut pas juste faire \S+\s+\S++, ça n’aurait aucun sens. Comment faire que ce dernier + sache à quoi il s’applique, en l’occurrence \s+\S+ ? Avec les groupes, pardi :

\S+(\s+\S+)+

Le groupe constitue une seule entité grammaticale, donc le quantificateur qui le suit s’applique au groupe dans son entier.

Grouper pour limiter une alternative

Un autre emploi fréquent du groupe est pour limiter une alternative (une utilisation de |, le pipe). Par défaut, on l’a vu, une alternative s’applique à tout ce qui l’entoure. Mais si elle figure au sein d’un groupe, elle se limite à ce groupe.

Supposons que vous vouliez autoriser les textes « hello world », « hallo world » et « hi world ». Le « world » étant commun on peut limiter l’alternative au premier mot. Mais si on fait ceci :

hello|hallo|hi world

…on se plante, car ça correspondrait à « hello », « hallo » ou « hi world », ce qui n’est pas ce qu’on veut. Il faut délimiter l’alternative avec un groupe :

(hello|hallo|hi) world

Et voilà, le tour est joué !

Grouper pour récupérer individuellement des fragments précis de la correspondance

Le dernier usage des groupes, qui est extrêmement utile, est la possibilité de référencer des portions spécifiques de la correspondance obtenue. Par exemple, vous essayez de repérer, au sein d’un texte, une chaîne française de date, au format jj/mm/aaaa. Non seulement vous voulez vérifier que la chaîne est bonne, mais aussi en extraire les composants. Au lieu de « juste » écrire ceci :

\d{2}/\d{2}/\d{4}

…vous pourriez isoler chaque composant dans son groupe :

(\d{2})/(\d{2})/(\d{4})

Vous allez alors obtenir, en plus de la correspondance globale (par exemple « 25/07/2012 ») des groupes 1 à 3 (« 25 », « 07 » et « 2012 »).

Les groupes sont numérotés de 1 à 9. Au-delà, vous ne disposez plus de numéros. Vous ne pouvez donc avoir recours « que » à 9 groupes numérotés dans une expression. On parle de groupes capturants.

Numérotation et imbrication de groupes

Il est naturellement possible d’imbriquer les groupes. Par exemple, comme ceci :

(\d{4}-(\d{2})-(\d{2}))

Mais alors, quel groupe a quel numéro, et quelle valeur ? La règle de numérotation est simple : dans l’ordre des parenthèses ouvrantes. Ainsi, sur le texte 2012-07-28, on obtiendrait :

• Le groupe 1 : 2012-07-28
• Le groupe 2 : 07
• Et le groupe 3 : 28

Backreferences (« backrefs »)

Dès l’instant où un groupe est numéroté, il devient possible de le référencer, tant pour un remplacement que pour une recherche.

Le cas de figure du remplacement est assez classique et utilise la syntaxe $numéro. Supposons que vous ayez à transformer des dates américaine (mois/jour/année) en dates techniques (année-mois-jour). On pourrait procéder ainsi :

1

usDate.replace(/(\d{2})\/(\d{2})\/(\d{4})/, '$3-$2-$1')

Là où ça devient vraiment pratique, c’est au sein même du motif de recherche. On s’en sert couramment pour faire correspondre des délimiteurs. Supposons que vous vouliez définir un motif qui autorise de part et d’autre l’apostrophe (') ou le guillemet ("), mais qui exige que les deux extrêmités correspondent. La version pourrie, ce serait :

'.+?'|".+?"

Et encore, elle pose plein de soucis. Mais vous pouvez facilement simplifier ça (surtout si ce qu’il y a entre les apostrophes/guillemets est un motif compliqué) en évitant toute répétition. Pour le cas où l’apostrophe/guillemet initial constituerait le premier groupe numéroté du motif :

(['"]).+?\1

Pratique, non ? Le \1 fait référence au texte qui a correspondu au groupe 1 : il faut alors que dans le texte analysé, on trouvé à l’endroit du \1 extactement le même texte que pour le groupe 1.

Groupes non capturants

Neuf groupes, c’est beaucoup et vous n’aurez normalement pas besoin de tous. En revanche, il arrive souvent que vous ne souhaitiez pas exploiter le groupe individuellement, et n’ayez donc pas besoin de lui attribuer un numéro. Par exemple, vous l’auriez utilisé uniquement pour une des autres raisons : quantifier une séquence ou limiter une alternative. Il est alors dommage de « polluer » les groupes numérotés légitimes avec ceux-là, vous obligeant à examiner les groupes 2, 6 et 9 au lieu de 1, 2 et 3. Comment faire ?

C’est tout simple, il suffit de recourir alors à des groupes non capturants. Par défaut, un groupe est capturant : il s’octroie un numéro. Mais lorsque vous l’utilisez juste à des fins structurelles, vous pouvez le rendre non capturant en préfixant son contenu par ?:. Ça donnerait quelque chose comme ça :

([A-Z]{2})(?:\.\d+)+([A-Z])

Dans l’exemple ci-dessous, on a d’abord un groupe capturant, qui comprend deux lettres latines majuscules : ([A-Z]{2}). C’est le groupe numéro 1. Puis on a un groupe non capturant, dont le seul objectif est de pouvoir ensuite appliquer à son contenu le quantificateur + : (?:\.\d+), à savoir un point suivi d’au moins un chiffre. Et finalement, on a un deuxième groupe capturant, qui aura donc le numéro 2 : ([A-Z]), soit une lettre latine majuscule.

En utilisant judicieusement la syntaxe non capturante, vous n’utilisez des numéros que pour les groupes que vous souhaitez effectivement référencer ensuite. En plus, un groupe capturant est souvent plus lourd à gérer par les moteurs de regex qu’un groupe non capturant : vous améliorez donc aussi, même si ce n’est pas toujours sensible, la performance de votre regex.

Indiquer la position avec les ancres

Jusqu’ici, nous avons rédigé des regex qui, dans la pratique, pouvaient correspondre à un texte figurant n’importe où dans la chaîne de caractères examinée.

Par exemple, la regex h[ea]ll?o correspondra bien sûr à hallo, hello et halo, mais aussi à hello world, say hello, mark! et surtout à chaloupe ou halogène.

Il arrive fréquemment qu’on ait besoin de préciser une contrainte de positionnement sur tout ou partie d’une regex. C’est le rôle des ancres.

Les regex JavaScript reconnaissent les ancres suivantes :

• ^ (circonflexe, en anglais caret). Il s’agit du début de la chaîne de caractère examinée. Si la regex utilise le drapeau multi-lignes (m), il peut en fait s’agir de n’importe quel début de ligne (début de texte ou juste après un saut de ligne, \n).
• $ (dollar). C’est la fin de la chaîne, ou en mode multi-ligne ce peut aussi être une fin de ligne.
• \b est le word Boundary. C’est une ancre extrêmement utile, qui désigne une bordure de mot. Ça inclut notamment les sauts de lignes, espaces, la ponctuation et les extrêmités du texte. Par symétrie, on a aussi \B (majuscule), qui comme pour les classes est le contraire de \b : elle indique qu’on ne se situe pas à la bordure d’un mot.

Quelques exemples :

^halo  // correspond à "halo" et "halogène" et "halo éclatant", mais pas à "chaloupe" ou "un halo."
halo$  // correspond à "halo", mais ni "halogène", ni "halo éclatant", ni "chaloupe", ni "un halo."
\bhalo // correspond à "halo", "un halo.", "halo éclatant" et "halogène", mais pas "chaloupe"
halo\b // correspond à "halo", "un halo." et "halo éclatant", mais ni "halogène" ni "chaloupe"

Ainsi, pour indiquer qu’une regex correspond à l’ensemble d’un texte, on l’encadre par ^ et $, comme ceci :

^h[ea]llo w(?:orld|elt)$ // "hello world", "hallo welt", "hello welt", "hallo world" et c'est tout.

Conditions sur la suite du texte (lookaheads)

Parfois, une contrainte sur position ne suffit pas. Il faut carrément indiquer une condition sur la suite du texte.

Lookaheads positifs

Peut-être quelque chose comme “un chiffre, à condition qu’il soit suivi par deux autres chiffres”. Mais on ne veut pas pour autant accumuler les deux chiffres qui suivent dans la correspondance. On utilise pour cela un positive lookahead, identifié comme un groupe avec un préfixe ?=  :

\d(?=\d\d) // "2" dans "237" ou "243", mais pas dans "24M", "2", "2TZ" ou "2T4".

Lookaheads négatifs

Il est évidemment possible aussi d’exprimer une contrainte négative sur la suite du texte : ce qu’on ne veut pas trouver après. Au lieu de ?=, on utilise alors ?!. Pour prendre l’inverse de l’exemple précédent, on pourrait dire “un chiffre, pourvu qu’il ne soit pas suivi par un autre chiffre” :

\d(?!\d) // "2" dans "2", "2TZ" ou "2T4", mais pas dans "237", "243" ou "24M".

Tout ça peut sembler un peu basique, mais voici un bel exemple combiné et imbriqué, et une fois que vous l’avez digéré, vous êtes au point sur les lookaheads ! Examinez plutôt :

1

numberString.replace(/(\d)(?=(\d\d\d)+(?!\d))/g, "$1 ")

Oh pétard ! Ça fait quoi, ça ?!?

Eh bien « tout simplement », ça ajoute les espaces en séparateurs de milliers entre les groupes de 3 chiffres (en partant de la droite, évidemment). En somme, grâce aux lookaheads, on arrive à analyser par la droite alors que les regex travaillent par la gauche.

Voilà de quoi vous faire tourner les méninges… Petite astuce pour décrypter cette regex : on cherche en fait à remplacer chaque fin de groupe numérique (hors le dernier) par son dernier chiffre suivi du séparateur. Et comment sait-on qu’on a des groupes numériques valables derrière soi ? Parce qu’on a un nombre de chiffres multiple de 3 derrière soi. Voilà, je vous laisse décortiquer tout ça… Quelques exemples de conversion :

'243'         // '243'
'2431'        // '2 431'
'24315'       // '24 315'
'243157'      // '243 157'
'2431576'     // '2 431 576'
…

Lookbehinds ?

Dans certains cas de figure, il peut être également utile de poser une contrainte sur le texte d’avant, indépendamment de comment on a éventuellement traversé ce texte dans un début de correspondance. On aurait alors recours aux lookbehinds, qui traditionnellement s’écrivent ?<= et ?<!. Cependant, JavaScript ne propose pas, en standard, cette syntaxe.

Et pour le coup, XRegExp ne permet pas de simuler cette possibilité. Il existe toutefois la possibilité de les simuler si besoin.

Les API JavaScript qui utilisent les regex

JavaScript nous permet de recourir aux regex au moyen de diverses API, certaines très connues, d’autres moins.

String#match et String#replace

Certainement les deux plus connues. On utilise la première pour chercher des correspondances, l’autre pour les remplacer.

Selon que la regex utilise le flag g ou non, on cherche (ou remplace) toutes les correspondances, ou seulement la première :

1
2

'hello world!'.match(/\w+/g) // => ['hello', 'world']
'hello world!'.match(/\w+/)  // => ['hello']

Ce que beaucoup ne savent pas, c’est que le résultat n’est pas juste un tableau, avec sa propriété length et les index numériques (0, 1, etc.). En tout cas, quand le drapeau g est absent. Il est alors aussi doté de propriétés spéciales : index, qui indique la position de la première correspondance, et input, qui reprend le texte complet analysé. Voyez plutôt :

1
2
3
4
5
6

var result = 'hello world!'.match(/\s(\w+)/)
result.length // => 2
result[0]     // => ' world' (la correspondance complète)
result[1]     // => 'world' (le groupe numéroté 1)
result.index  // => 5 (la position, en partant de 0, de la correspondance complète dans le texte)
result.input  // => 'hello world!' (le texte analysé)

Quant à replace, elle accepte en fait deux formats pour son deuxième argument (qui décrit le remplacement).

Le premier format est une chaîne de caractères : c’est le motif de remplacement. On peut alors y trouver les syntaxes spéciales :

$& (la correspondance complète)
$` (le texte avant la correspondance)
$' (le texte après)
$1 à $9 (les groupes numérotés).

Par exemple :

1

'hello world!'.replace(/\w+/g, '[$&]')   // => '[hello] [world]!'

On peut aussi, et c’est là que ça devient balèze, utiliser une fonction, qui prend alors comme arguments la correspondance totale, les groupes numérotés, l’index de début de correspondance et au final le texte analysé d’origine. La fonction renvoie le texte qui remplacera la correspondance globale. Voyez plutôt :

1
2
3
4

'HELLO WORLD!'.replace(/\b(\w)(\w*)/g, function(word, initial, remainder) {
  return initial.toUpperCase() + remainder.toLowerCase();
})
// => 'Hello World!'

String#split

La plupart des développeurs connaissent split, par exemple comme ci-dessous :

1

'hello world this is nice'.split(' ')  // => ['hello', 'world', 'this', 'is', 'nice']

Mais beaucoup ne savent pas, et c’est dommage, que le séparateur peut être une regex. Ainsi, imaginez le texte suivant :

1

'01-17.32  28--17/41'

Pour extraire les groupes numériques, avec un séparateur textuel, on est dans la mouise. Mais avec une regex, aucun souci :

1

'01-17.32  28--17/41'.split(/\D+/)  // => ['01', '17', '32', '28', '17', '41']

String#search

Pour information, il existe aussi une API search qui vous renvoie uniquement la position de la correspondance (-1 si introuvable), et non tout le détail que renvoie match. Du coup, si c’est la seule info qui vous intéresse (la position), c’est plus performant.

RegExp

Les regex JavaScript sont toutes des objets (comme presque toujours en JavaScript), en l’occurrence des instances de RegExp. Elles ont notamment deux méthodes : exec et test.

Voici deux expressions rigoureusements équivalentes :

1

/\w+/.exec('hello world!') // <=> 'hello world!'.match(/\w+/)

Le drapeau g est sans effet sur exec, en revanche. On tape toujours dans la première correspondance. Le résultat renvoyé est strictement identique à celui décrit pour match, avec les propriétés numériques ainsi que index et input.

Si tout ce qui vous intéresse, c’est qu’il y ait ou non correspondance, vous pouvez vous contenter de test, qui renvoie un simple booléen et s’exécute donc plus rapidement (un peu comme tout à l’heure, avec la différence entre match et search).

Il est donc possible de créer dynamiquement une regex, avec new RegExp(motif, drapeaux). Le seul intérêt, naturellement, par rapport à un litéral, c’est si le contenu du motif (ou des drapeaux) varie avec le temps, par exemple suite à une saisie utilisateur.

Supposons que vous autorisiez l’internaute à taper des lettres qui servent de filtre de recherche, ce qu’on appelle une fuzzy search : ça correspondrait à tout texte où ces lettres existent dans l’ordre, peu importe ce qu’il y aurait entre elles.

Par exemple, pour la saisie jel, vous voudriez rechercher tout texte contenant un j, plus loin un e et encore plus loin un l. En somme, la regex serait j.*e.*l. Supposons que la saisie soit effectuée dans un champ dont l’attribut id vaudrait filter :

1
2

var expr = document.getElementById('filter').value;      // $('#filter').val() avec jQuery…
var regex = new RegExp(expr.split('').join('.*'), 'g');  // Peu importe la casse…

En réalité, pour que cet exemple soit vraiment blindé, il faudrait d’abord “échapper” les caractères spéciaux saisis (spéciaux au sens des regex), en les préfixant par un backslash (\), mais vous saisissez l’idée.

C’est bien là la seule raison de recourir à new RegExp (ainsi peut-être qu’un motif bourré de slashes (/)). Le reste du temps, un litéral est plus concis et plus performant.

Mise en application

Afin de vous permettre de vous faire la dent, voici quelques exercices pour pratiquer.

Exo 1

Prenez le premier paragraphe de ce lorem ipsum et collez-le dans une String. Extrayez-en les mots de plus de 4 lettres non suivis d’une espace.

Voir la solution sur JSBin

Exo 2

Parmi les acronymes connus commençant par AC, sortez tout ceux comportant une répétition consécutive de lettres, quelles qu’elles soient.

Voir la solution sur JSBin

Exo 3

Examinez le HTML résultat de cette recherche Google et sortez les titres, URLs et positions (au sein des résultats naturels uniquement) des pages JS Attitude.

Voir la solution sur JSBin

Étendre les regex JavaScript : XRegExp

Bien que le moteur de regex de JavaScript ne soit pas mauvais (et plutôt rapide), à l’usage, on regrette rapidement l’absence de certaines fonctionnalités présentes dans des moteurs plus récents comme ceux qu’on peut trouver dans les versions actuelles de Perl, Python ou Ruby, pour ne citer qu’eux.

Heureusement, grâce au boulot acharné de Steve Levithan, fan de regex et de JavaScript, il existe un palliatif de premier choix : l’excellente bibliothèque XRegExp.

Celle-ci nous offre de nouvelles syntaxes, de nouveaux drapeaux de traitement, et va même jusqu’à corriger quelques bugs exotiques des moteurs de regex proposés par les principaux navigateurs.

Comment exploiter XRegExp ?

XRegExp n’est pas natif à JavaScript, aussi les litéraux de type /…/ ne peuvent pas s’en servir automatiquement. Il faut recourir à la fonction XRegExp, qui a les mêmes arguments que le constructeur new RegExp : le motif et les drapeaux. Par exemple :

1

var regex = XRegExp('<p class="result">.+?</p>', 'is');

Cette syntaxe a un léger inconvénient (évidemment) : puisqu’on est dans un litéral chaîne de caractères et non un litéral regex, il va falloir doubler tous les backslashes. Ainsi, /\w+\s donnera XRegExp('\\w+\\s').

Là où les instances de RegExp et String ont des méthodes directes, XRegExp a choisi d’avoir une API 100% « statique », appelable dans l’espace de nom XRegExp. Ce ne sont pas des méthodes sur les objets retournés par XRegExp(…). On trouve donc une méthode XRegExp.exec et une méthode XRegExp.test, mais il y a aussi les équivalents des méthodes complémentaires disponibles sur String : split et replace. Par ailleurs, l’API de XRegExp fournit de nombreuses méthodes utilitaires, comme forEach pour itérer facilement sur les correspondances, escape et build pour construire dynamiquement une regex depuis des fragments divers, et j’en passe. Jetez un œil à l’API complète.

Groupes capturants nommés

XRegExp nous fournit de nombreuses améliorations syntaxiques. Celle qui est de loin ma préférée consiste à permettre de nommer les captures. Ainsi, plutôt que d’avoir un bête numéro de 1 à 9, on a un nom explicite. Par exemple, au lieu de ceci :

1

/(\w+)\s+\1/

…on peut préférer ceci (certes plus long, mais plus explicite) :

1

XRegExp('(?<word>\\w+)\s+\\k<word>)

Nous verrons des exemples plus « percutants » tout à l’heure, en combinant cette possibilité avec la syntaxe étendue.

Un groupe nommé est forcément capturant (il se voit donc aussi affecter un numéro, comme une capture usuelle), et démarre par le préfixe ?<nom>. Une backref nommée, au lieu d’être backslash + numéro, est \k<nom>.

Ce qui est vraiment sympa, c’est que cette prise en charge va jusqu’au bout :

• Dans les textes de remplacement utilisés comme deuxième argument de replace : on a droit à la syntaxe ${nom}.
• Dans les propriétés de l’objet résultat renvoyé par match et transmis aux fonctions de remplacement : en plus des propriétés numériques usuelles, on a des propriétés nommées comme le groupe.

1
2
3
4

var regex = XRegExp('(?<word>\\w+)\s+\\k<word>');
var text = 'Franchement XRegExp XRegExp ça déboite !';
var result = XRegExp.exec(text, regex);
result.word // => 'XRegExp'

XRegExp fournit encore d’autres possibilités, telles que les commentaires monoligne intégrés ou les commutateurs de mode à la volée, mais je leur trouve peu d’intérêt. Vous pouvez en savoir plus sur la page des syntaxes proposées par XRegExp.

Nouveaux drapeaux

XRegExp introduit par ailleurs trois nouveaux drapeaux qui altèrent le fonctionnement standard du moteur. En plus des drapeaux usuels (i, m et g), on trouve désormais :

• s pour Singleline. Ce mode est également connu sous le nom « dotall », et signifie que le caractère générique . (point) peut correspondre à véritablement n’importe quoi, y compris des sauts de ligne (4 caractères Unicode possibles, dont \n et \r). Extrêmement pratique quand on traite du HTML et qu’on veut extraire des balises de contenu…
• n est le drapeau de capture explicite. Avec lui, seules les groupes nommés sont capturants : les groupes non nommés n’ont plus besoin d’être préfixés par ?: pour être non capturants.

• x est le eXtended mode, votre nouveau meilleur ami. Il permet d’utiliser un espacement libre et aussi des commentaires de fin de ligne. Prenons l’exemple d’une analyse de date au format A-M-J :

  (\d{4})-(\d{2})-(\d{2})

Pas horrible, mais pas top non plus. On pourrait faire :

1
2
3
4
5

XRegExp('(\\d{4}) # Year \
         - \
         (\\d{2}) # Month \
         - \
         (\\d{2}) # Day')

Déjà plus lisible, non ? Grâce à la possibilité d’ignorer les espacements non qualifiés, tout espacement litéral est considéré comme ignorable dans le motif. À vous d’utiliser une autre syntaxe (le générique \s ou une entité numérique spécifique) en cas de besoin.

On peut remplacer (ou augmenter) ces commentaires assez simples en nommant les captures :

1

XRegExp('(?<year>\\d{4}) - (?<month>\\d{2}) - (?<day>\\d{2})')

Du coup, l’objet résultat n’aurait pas seulement des propriétés 1, 2 et 3, mais aussi et surtout year, month et day.

Et maintenant une décomposition d’URL pas trop tatillonne :

1
2
3
4
5
6
7
8
9
10
11
12

var regex = XRegExp('^(?<scheme> [^:/?]+ ) ://   # aka protocol   \n\
                  (?<host>   [^/?]+  )       # domain name/IP \n\
                  (?<path>   [^?]*   ) \\??  # optional path  \n\
                  (?<query>  .*      )       # optional query', 'x');
var text = 'http://google.com/path/to/file?q=1';

var parts = XRegExp.exec(text, regex);
parts        // => ['http://google.com/path/to/file?q=1', 'http', 'google.com', '/path/to/file', 'q=1']
parts.scheme // => 'http'
parts.host   // => 'google.com'
parts.path   // => '/path/to/file'
parts.query  // => 'q=1'

Add-ons et prise en charge d’Unicode

Dans un web en UTF-8, l’incapacité de RegExp à gérer Unicode, que ce soient pour les espacements, les lettres ou les chiffres, devient de plus en plus gênante. XRegExp propose des add-ons pour diverses fonctions, au premier rang desquels la capacité à détecter des catégories Unicode. À noter que XRegExp gère déjà correctement les espacements Unicode (et notamment l’espace insécable, code 160) avec \s (donc \\s…).

FIXME: VERIFY THIS \s CLAIM!

De telles catégories sont alors utilisables dans les motifs de correspondance avec la syntaxe \\p{X} (où X est la lettre abrégée de la catégorie) ou \\p{Category} (avec le nom complet).

• Unicode Base fournit la catégorie la plus critique : Letter (abréviation L).
• Categories fournit les catégories/propriétés Unicode, telles que Lowercase Letter, Uppercase Letter, Number ou Punctuation.
• Scripts fournit tous les scripts (langues) définis par l’Unicode Multilingual Plane, tels que Latin, Arabic, Greek, Tamil…
• Blocks fournit les blocs Unicode, sortes de sous-ensembles des scripts, tels que InLatin_Extended_A ou InControl_Pictures.
• Properties est un complément de Categories, nécessaire à la prise en charge d’Unicode dite « niveau 1 ». On y trouve des séries telles que Alphabetic, WhiteSpace, Ascii ou Assigned.

Le site officiel reprend notamment ces exemples :

1
2
3
4
5
6
7
8
9
10
11
12
13
14

// Categories
XRegExp('\\p{Sc}\\p{N}+'); // Sc: currency symbol, N: number

// Scripts
XRegExp('\\p{Cyrillic}');
XRegExp('[\\p{Latin}\\p{Common}]');

// Blocks (use 'In' prefix)
XRegExp('\\p{InLatinExtended-A}');
XRegExp('\\P{InPrivateUseArea}'); // Uppercase \P for negation
XRegExp('\\p{^InMongolian}'); // Alternate negation syntax

// Properties
XRegExp('\\p{Assigned}');

Les addons sont à charger après le script de base. Le site officiel fournit une version totale déjà minifiée, pour ceux qui en ont souvent besoin et préfèrent réduire le nombre de fichiers.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

<script src="xregexp.js"></script>
<script src="addons/unicode/unicode-base.js"></script>
<script>
  var unicodeWord = XRegExp("^\\p{L}+$");

  unicodeWord.test("Русский"); // true
  unicodeWord.test("日本語"); // true
  unicodeWord.test("العربية"); // true
</script>

<!-- \p{L} is included in the base script, but other categories, scripts,
and blocks require token packages -->
<script src="addons/unicode/unicode-scripts.js"></script>
<script>
  XRegExp("^\\p{Katakana}+$").test("カタカナ"); // true
</script>

Vous pouvez consulter la liste complète des add-ons XRegExp.

Quand ne pas utiliser les expressions rationnelles ?

On a principalement deux cas :

• Le besoin est suffisamment simple pour être traité plus rapidement par des moyens textuels classiques ; comme un moteur de regex sera toujours plus lourd / plus lent qu’un traitement textuel basique, recourir à une regex serait alors inutilement bourrin.
• Le besoin est trop compliqué pour être traité de façon fiable par les regex ; la syntaxe des regex ne permet pas d’exprimer tout et n’importe quoi. Au-delà d’une certaine limite, on a besoin d’un moteur plus adapté à la nature du texte examiné, quitte à mélanger les approches entre moteur dédié, textuel basique et regex.

On serait dans le premier cas pour détecter, par exemple, la position/présence d’un texte fixe au sein d’une chaîne de caractères.

En revanche, tout traitement basé sur la sémantique du texte est pénible en regex. Celles-ci opèrent, fondamentalement, au niveau du caractère, pas de la sémantique d’ensemble. Quelques exemples classiques devraient vous aider à établir la distinction.

L’analyse du XML/HTML est, de façon générale, difficile en regex. On peut bien sûr procéder à quelques extractions simples, comme avec l’exercice de tout-à-l’heure sur les liens de résultats naturels chez Google. Mais corréler deux liens entre eux ? Déterminer si certains liens ont telle ou telle propriété ? Comptabiliser des caractéristiques ? C’est une autre paire de manches, qui requiert soit un complément d’analyse sur l’extraction produite, soit une traversée par un mécanisme plus dédié au problème (en l’occurrence le DOM, XPath et un algorithme à soi).

Prenons un autre exemple très simple : déterminer la validité d’une adresse IP classique (une adresse IPv4). On a besoin de vérifier au minimum deux éléments :

1. On a affaire à 4 nombres séparés par un point
2. Chaque nombre est entre 0 et 255

Le premier point est déjà un peu balourd en regex, qui n’a pas d’opérateur « séparé par », et nous obligerait à répéter un motif. Mais le deuxième point, qui se penche sur la sémantique du nombre, illustre toute la limite des regex. L’expression nécessaire montre à quel point on travaille au niveau du caractère :

[01]?[0-9]{1,2}|2[0-4][0-9]|25[0-5]

Ce qui donne tout de même, pour l’ensemble :

(?:[01]?[0-9]{1,2}|2[0-4][0-9]|25[0-5]\.){3}[01]?[0-9]{1,2}|2[0-4][0-9]|25[0-5]

Alors qu’ici, un traitement textuel classique est amplement suffisant. Voici une possibilité qui essaie d’être efficace (au sens où elle « répond » aussitôt que possible) :

1
2
3
4
5
6
7
8
9
10
11

function isIPv4(text) {
  var components = text.split('.');
  if (4 != components.length)
    return false;
  for (var index = 0; index < 4; ++index) {
    var comp = parseInt(components[index], 10);
    if (comp < 0 || comp > 255)
      return false;
  }
  return true;
}

Oui, c’est plus long. Mais c’est aussi plus rapide à analyser et comprendre pour quelqu’un qui ne passe pas ses journées dans les regex…

Quelques outils pour aider à la construction

Lorsqu’on découvre et pratique les regex, un bon outil est souvent utile. Il doit permettre de visualiser facilement quelles sont les correspondances, quels sont les groupes constitués, etc. En voici une petite sélection :

• Regexr est en AIR mais je lui pardonne… Il permet aussi de sauver ses regex et de consulter une liste notée par les autres internautes (à examiner avec précaution, comme toujours).
• Rubular est un outil en ligne basé sur les moteurs Ruby (mais c’est très similaire à JavaScript + XRegExp).
• RegexBuddy est un excellent p’tit outil pas mal foutu qui affiche notamment le détail du fonctionnement des correspondances. En revanche, il a un vrai défaut : il ne marche que sur Windows.

Pour conclure…

Bon, j’ai décidément mis beaucoup trop de temps à écrire cet article. Mais il est finalement là, et j’espère qu’il vous aura plu, et donné envie d’explorer davantage les possibilités qu’elles offrent pour votre développement au quotidien.