Les points-virgules en JavaScript : le guide définitif

C’est une des questions que les débutants posent régulièrement après avoir lu du code JavaScript sans point-virgule à la fin des lignes.

Est-ce que les points-virgules en JavaScript sont obligatoires ?

J’ai décidé de créer un guide définitif pour répondre à cette question une bonne fois pour toute de façon claire, précise et documentée. Si on vous pose la question, vous n’aurez qu’à donner le lien vers ce guide !

Note : je n’ai rien contre les développeurs qui n’utilisent pas les points-virgules, chacun est libre de faire ce qu’il veut. Mais ne véhiculez pas de fausses informations sur leur utilité ou non, merci.

Pour ceux qui se demandent, en JavaScript je code avec les points-virgules par réflexe (car j’ai longtemps codé en C et Java). Et dans ma formation JavaScript, j’ai fait le choix d’utiliser les points-virgules pour les raisons que j’explique en vidéo ici.

Est-ce que les points-virgules en JavaScript sont obligatoires ?

Direction la source technique du langage JavaScript, j’ai nommé la spécification ECMAScript. À l’heure où j’écris ces lignes, la dernière version est la version 9 (version en PDF) qui date de Juin 2018.

Elle stipule clairement que la majorité des instructions du langage doivent être terminées par un point-virgule.

Traduction du texte surligné : la plupart des instructions et déclarations ECMAScript doivent être terminées par un point-virgule.

Quelques exemples de grammaire du langage :

Les points-virgules doivent être indiqués pour terminer une instruction, et ce, avant que le code ne soit exécuté par l’interpréteur JavaScript.

Pourtant, on dit souvent (à tort) qu’ils sont optionnels car un système nommé ASI permet de les ajouter à la volée s’ils ne sont pas présents dans le code source.

L’ASI permet l’omission des points-virgules par commodité

ASI signifie Automatic Semicolon Insertion. En Français : insertion de point-virgule automatique.

L’ASI est un système qui est prévu par la spécification ECMAScript comme indiqué à la section 11.9 de celle-ci :

Extrait de la section 11.9 concernant l’ASI dans la spécification ECMAScript 9

Je vous traduis cette section :

La plupart des instructions et déclarations ECMAScript doivent être terminées avec un point-virgule. Ces mêmes points-virgules devraient toujours apparaître explicitement dans le texte source.

Par commodité, pourtant, ces points-virgules peuvent être omis du texte source dans certaines situations. Ces situations sont décrites en disant que les points-virgules sont automatiquement insérés dans le flux de symboles du code source dans ces situations.

Autrement dit, dans certaines situations, on peut se passer de mettre un point-virgule à la fin d’une instruction, c’est l’ASI (qui fait partie intégrante de l’interpréteur JavaScript) qui se chargera de l’ajouter avant l’exécution de notre code source.

La suite de la spécification indique les règles d’ajout automatique de point-virgule et décrit les différentes situations qui peuvent provoquer des erreurs d’interprétation du code.

Je ne vais pas énumérer toutes les règles ici mais simplement vous présenter les avantages et inconvénients souvent cités de mettre (ou pas) les points-virgules. Je parlerai des cas particuliers de code juste après.

Arguments POUR les points-virgules

Utiliser les points-virgules par facilité

L’ASI contient certaines règles et exceptions parfois difficiles à retenir qui peuvent provoquer une mauvaise interprétation de notre code.

Il est plus simple de mettre les points-virgules tout le temps comme ça on n’a pas à se soucier des cas particuliers. Lorsqu’on utilise les points-virgules on ne risque aucune erreur. Si on ne les utilise pas on risque de tomber sur certaines erreurs.

Peur du futur et du système

Mettre les points-virgules permet de se prémunir d’une éventuelle complication des règles de l’ASI au fur et à mesure que de nouvelles fonctionnalités vont être ajoutées au langage JavaScript.

Si la spécification venait à changer sur ce sujet, le code écrit sans point-virgule ne fonctionnerait plus (voir Mythe n°4 ci-dessous !).

L’ASI est un système de secours, compter la dessus c’est comme rouler vite en voiture parce qu’on a une ceinture de sécurité, ce n’est pas prudent.

Cohérence ou préférence personnelle

Parce qu’on a codé en C ou Java dans le passé et les mettre est devenu un réflexe.

Si on doit écrire du code C ou Java dans le même projet que son code JavaScript, on veut des points-virgules partout pour rester cohérent entre les différents langages : les points-virgules sont obligatoires dans le langage C et Java.

Ça rend le code plus lisible et enlève toute ambiguïté : on sait quand l’auteur a voulu mettre fin à une instruction.

Arguments CONTRE les points-virgules

C’est plus facile

On gagne du temps à ne pas les taper quand on code.

Le peu de cas particuliers qui posent problème ne justifie pas de mettre les points-virgules.

C’est plus simple à lire et plus facile à apprendre pour un débutant.

Préférence personnelle

C’est plus joli un code sans points-virgules !

Je connais mieux le langage JavaScript

Ce sont les développeurs fainéants qui ne veulent pas penser, qui mettent des points-virgules partout pour éviter d’apprendre les règles de l’ASI.

Si vous connaissiez le langage avec lequel vous codiez, vous n’auriez pas peur de ne pas mettre les points-virgules.

Conclusion sur les arguments

Comme vous le voyez, il y a beaucoup d’arguments basés uniquement sur les préférences personnelles comme : je trouve ça plus joli avec ou sans, c’est un réflexe que j’ai car je connais d’autres langages qui nécessitent les points-virgules etc.

Il y a au final assez peu d’arguments techniques pour ou contre l’utilisation des points-virgules.

En revanche, il y a pas mal de mythes et légendes qui traînent sur internet… Il me semble important de démystifier tout ça une bonne fois pour toute.

Mythes concernant l’omission des points-virgules

Mythe n°0 : certains interpréteurs JavaScript ne gèrent pas les points-virgules manquants

Un interpréteur JavaScript doit respecter la norme ECMAScript. La norme définit l’ASI comme étant partie intégrante et obligatoire du langage JavaScript (section 11.9 de la spécification ECMAScript).

Par conséquent tous les interpréteurs JavaScript se doivent d’implémenter l’ASI et doivent donc être capables de lire un programme rédigé sans les points-virgules.

Mythe n°1 : on ne peut pas minifier son code sans les points-virgules.

Minifier son code consiste à réduire la taille de son code source au maximum en supprimant tout ce qui est inutile avant de l’envoyer à l’interpréteur JavaScript (ou sur le réseau pour le cas d’une page Web).

En l’occurence, on supprime les commentaires, les espaces inutiles et les retours à la ligne.

Par exemple ce code sans points-virgules :

// Voici du code avec des espaces, des commentaires et
// des retours à la ligne

const nombre = 42

// On teste la parité d'un nombre grâce au modulo
if (nombre % 2 === 0) {
  console.log('Ce nombre est pair')
} else {
  console.log('Ce nombre est impair')
}

Sera transformé sur une seule ligne après minification :

const nombre=42;if(nombre%2===0){console.log('Ce nombre est pair')}else{console.log('Ce nombre est impair')}

Puisqu’il est sur une seule ligne, on a besoin de séparer chaque instruction, et pour ça, le minifier se doit d’ajouter les points-virgules au code.

Si le minifier que vous utilisez n’ajoute pas les points-virgules à votre code, c’est qu’il est bogué ! Vous devez changer d’outil !

Tout code JavaScript valide, c’est-à-dire qui est correctement exécuté par un interpréteur JavaScript, doit pouvoir être minifié sans aucun problème et s’exécuter de la même façon après minification.

Mythe n°2 : mettre les points-virgules accélère votre programme

L’approche est de dire que parce vous ne mettez pas les points-virgules, l’ASI doit s’exécuter et donc l’interpréteur « perd » du temps à savoir s’il faut (ou pas) mettre un point-virgule ici ou là dans votre programme.

Ce qui aurait pour effet de ralentir l’interprétation ou l’exécution du programme.

Il n’y a aucune évidence à l’heure actuelle que c’est le cas. Le peu de tests effectués (sur jsPerf, voir ici et ) ne démontrent pas de différence significative de vitesse d’exécution pour tirer des conclusions à ce sujet.

Par ailleurs même si c’était le cas, les optimisations récentes des processeurs et de la compilation juste à temps (Just In Time compilation) rendraient le gain de temps complètement négligeable.

Mythe n°3 : certains navigateurs ne traitent pas l’absence des points-virgules de la même façon

Les règles de l’ASI sont standardisées et spécifiées dans la norme ECMAScript depuis très longtemps. Par conséquent, tous les navigateurs et interpréteurs JavaScript respectent les mêmes règles.

Si l’interpréteur ne respecte pas les règles de l’ASI, c’est qu’il est bogué.

Mythe n°4 : dans le futur l’ASI pourrait être enlevé de la spécification !

C’est une peur infondée.

En effet, même s’il existe des modifications qui cassent la compatibilité avec les versions précédentes d’ECMAScript comme l’indique la section E de la norme :

Addition et changements qui introduisent des incompatibilités avec les éditions précédentes

Ces modifications restent mineures et le comité TC39 qui gère la rédaction de la norme ECMAScript sait qu’il casserait des centaines de milliers de programmes et librairies écrits sans points-virgules s’il faisait le choix de retirer l’ASI de la norme.

Pour être techniquement juste, le TC39 obligerait les auteurs de ces programmes à ajouter les points-virgules manquants dans le code source, rien ne serait « cassé » à proprement parler.

Par conséquent la probabilité que cela se produise est vraiment très faible pour ne pas dire inexistante tant les conséquences seraient pénibles.

Maintenant que j’ai fini de casser quelques mythes, discutons des problèmes qu’il est possible de rencontrer si on décide de ne pas mettre de points-virgules.

Problèmes possibles dûs à l’absence de points-virgules

Lorsque vous ne mettez pas de points-virgules dans votre code, vous devez connaître les règles de l’ASI pour ne pas faire d’erreur et être sûr que votre programme sera interprété comme il faut.

Première chose à savoir, 99% du temps on remplace l’utilisation du point-virgule par un retour à la ligne pour indiquer à l’ASI une fin d’instruction possible.

Mais l’ASI ne considère pas le retour à la ligne directement comme une fin d’instruction, certaines conditions supplémentaires décrites dans les règles de l’ASI doivent être remplies pour ajouter le point-virgule manquant.

Les problèmes arrivent lorsque deux lignes séparées par un ou plusieurs retours à la ligne sont une instruction valide si on les colle ensemble (en supprimant les retours à la ligne qui ne sont d’aucune utilité pour le programme).

Voici quelques cas particuliers, la liste n’est pas exhaustive. Si vous en avez d’autres en stock, dites-le moi dans les commentaires, je les ajouterai !

Note : pour chaque solution j’utilise une convention qui veut qu’on mette le point-virgule manquant au début de la ligne posant problème. Mais il est tout à fait possible de mettre ce point-virgule à la fin de la ligne précédente.

Expressions régulières

let a = ''
let b = 'bonjour, je suis un cas particulier'
a = b
/bonjour/g.exec(b)

// Ce sont les deux dernières lignes qui posent problème car on 
// peut les coller ensemble et former une instruction valide !
// La division de b par bonjour et par le résultat de g.exec(b) :
a = b /bonjour/g.exec(b)

Ce programme ne s’exécutera pas et produira l’erreur suivante :

/bonjour/g.exec(b);
 ^
ReferenceError: bonjour is not defined

L’erreur est logique, l’interpréteur voit b / bonjour qu’il considère comme étant une division avec une variable nommée bonjour. Or cette variable n’est pas définie d’où le message d’erreur.

Pour corriger ce problème, les adeptes du code sans point-virgule préfixent la ligne posant problème /bonjour/g.exec(b) par un point-virgule :

let a = ''
let b = 'bonjour, je suis un cas particulier'
a = b
;/bonjour/g.exec(b) // <- point-virgule en début de ligne

Les opérateurs de post (inc|dec)rémentation

Les opérateurs de post-incrémentation ++ et -- doivent être placés directement après leur opérande, aucun retour à la ligne n’est permis. Par conséquent :

// Ce code n'a pas de sens, c'est juste pour expliquer le principe
i
++
j

// Sera converti par l'ASI en :
i;
++j;

// Et non pas comme ça :
i++;
j;

Les parenthèses en début de ligne

let phrase = 'Gérer les points-virgules est '
let fin = 'complexe'
phrase += fin
(phrase).replace('complexe', 'simple')

// ...sera converti par l'ASI en :
let phrase = 'Gérer les points-virgules est ';
let fin = 'complexe';
phrase += fin(phrase).replace('complexe', 'simple');

Ce code produit l’erreur suivante :

phrase += fin
          ^
TypeError: fin is not a function

Et oui, il tente d’appeler la fonction fin(phrase) or fin n’est pas une fonction. Pour corriger le code on préfixe la dernière ligne d’un point-virgule comme ceci :

let phrase = 'Gérer les points-virgules est '
let fin = 'complexe'
phrase += fin
;(phrase).replace('complexe', 'simple')

Les IIFE

On a un problème similaire avec les IIFE (fonctions immédiatement invoquées) :

let premiereFonction = function () {
  console.log('Je suis vivante')
}

// On utilise une IIFE
(function deuxiemeFonction() {
  console.log('Moi aussi')
})()

// L'ASI va convertir ce code en :
let premiereFonction = function () {
  console.log('Je suis vivante');
} (function deuxiemeFonction() {
  console.log('Moi aussi');
})();

Ce code va produire l’erreur : 

})();
  ^
TypeError: (intermediate value)(...) is not a function

Cet exemple est un poil plus complexe à comprendre.

En JavaScript, vous pouvez invoquer une fonction au moment de sa déclaration. Autrement dit, il est parfaitement correct de faire :

let premiereFonction = function() {
  console.log('Je suis vivante')
}()    // <- Notez l'appel immédiat à l'aide des parenthèses ici

C’est ce que l’ASI pense qu’on veut faire en passant comme argument la deuxième fonction :

let premiereFonction = function () {
  console.log('Je suis vivante');
} (function deuxiemeFonction() {
  console.log('Moi aussi');
  // L'ASI utilise deuxiemeFonction comme argument pour invoquer 
  // premiereFonction !
})();

Dernière étape les parenthèses vides de la dernière ligne. Elles sont parfaitement valides également si deuxiemeFonction renvoyait elle-même une fonction !

Cette fonction renvoyée serait immédiatement invoquée à son tour grâce aux parenthèses vides de la fin.

C’est pour ça que le message d’erreur indique (intermediate value) is not a function. Dans notre exemple l’intermediate value est deuxiemeFonction, celle-ci ne renvoie pas de fonction, l’appel final causé par les parenthèses vides sur la dernière ligne ne peut donc pas se faire, d’où l’erreur.

Pour corriger, il faut mettre un point-virgule juste avant l’IIFE :

let premiereFonction = function () {
  console.log('Je suis vivante')
}

;(function deuxiemeFonction() { // <- point-virgule au début
  console.log('Moi aussi')
})()

Les tableaux en début de ligne

Lorsqu’on utilise les tableaux en début de ligne et qu’on omet le point-virgule sur la ligne précédente on se heurte souvent au fait qu’ils peuvent être interprétés comme étant un accès à l’item d’un tableau de la ligne précédente.

Démonstration :

let monObjet = { Bonjour: [1,2,3] }
['Salut', 'Bonjour'].forEach(function(valeur) {
  console.log(valeur + " " + monObjet + "<br />")
})

// L'ASI va le convertir en :
let monObjet = { Bonjour: [1,2,3] } ['Salut', 'Bonjour'].forEach(function(valeur) {
  console.log(valeur + " " + monObjet + "<br />");
});

Ce code produit l’erreur suivante :

  console.log(valeur + " " + monObjet + "<br />")
                             ^
ReferenceError: monObjet is not defined

Une fois de plus, c’est parfaitement logique.

Une fois que l’ASI a interprété notre code, c’est comme si on déclarait un objet nommé monObjet et qu’on accédait immédiatement à la valeur de la clé représentée par ['Salut', 'Bonjour'] de cet objet : 

let monObjet = { Bonjour: [1,2,3] } ['Salut', 'Bonjour']...

Étrange comme nom de clé vous me direz !

Mais ici la virgule n’est pas une virgule de séparation d’éléments d’un tableau… Non.

Elle agit en tant qu’opérateur JavaScript virgule dont la fonction est d’évaluer de gauche à droite les instructions séparées par les virgules et de renvoyer la valeur de sa dernière opérande.

Autrement dit ['Salut', 'Bonjour'] va devenir tout simplement ['Bonjour'].

Regardons pas à pas ce que ça donne avec le code de l’ASI :

// Le code converti par l'ASI :
let monObjet = { Bonjour: [1,2,3] } ['Salut', 'Bonjour'].forEach(function(valeur) {
  console.log(valeur + " " + monObjet + "<br />");
});

// devient...
let monObjet = { Bonjour: [1,2,3] } ['Bonjour'].forEach(function(valeur) {
  console.log(valeur + " " + monObjet + "<br />");
});

// On accède donc à la valeur de la clé "Bonjour" de l'objet 
// monObjet c'est-à-dire au tableau [1,2,3]
let monObjet = [1,2,3].forEach(function(valeur) {
  console.log(valeur + " " + monObjet + "<br />");
});

Le code s’exécute mais plante au moment d’accéder à monObjet car celui-ci n’est pas accessible puisque nous n’avons pas terminé sa déclaration !

En effet on est toujours dans la déclaration de celui-ci au moment où ce code est exécuté !

D’où le message d’erreur comme quoi il n’est pas défini.

Pour corriger ce code, on peut mettre un point-virgule devant la ligne commençant par le crochet ouvrant :

let monObjet = { Bonjour: [1,2,3] } 
;['Bonjour'].forEach(function(valeur) {
  console.log(valeur + " " + monObjet + "<br />");
});

Un autre exemple avec une chaîne de caractère précédent l’utilisation d’un tableau :

let clavier = 'azerty'
[1,2,3].forEach(function(value){console.log(value)})

// Ce code produira l'erreur Object r has no method 'forEach'
// Vous savez pourquoi maintenant ;-). On accède au caractère 3 
// de clavier qui est la lettre r et on tente de faire un forEach dessus !

BONUS: L’instruction return

L’instruction return peut retourner une valeur… ou pas. Si elle retourne une valeur, elle doit commencer à le faire sur la même ligne.

// Cette fonction retourne un objet avec ['statut'] => 'ok'
function retourneMoiUnObjet() {
  return {
    statut: 'ok'
  }
}

// Cette fonction ne retournera rien
function retourneMoiUnObjet() {
  return
  {
    statut: 'ok'
  }
}

// En effet elle sera transformée par l'ASI comme ceci :
function retourneMoiUnObjet() {
  return; // <- sort immédiatement de la fonction !
  {
    statut: 'ok';
  }
}

J’ai inclus cet exemple car il est souvent cité dans les guerres entre développeurs portant sur l’utilisation du point-virgule alors qu’il n’a rien à voir avec ça.

C’est le retour à la ligne qui pose problème ici, pas l’utilisation du point-virgule.

BONUS: Les fichiers qui commencent par un point-virgule

Vous avez peut-être déjà vu des fichiers de librairies JavaScript commencer par un point-virgule comme ceci :

/**
 * Librairie JavaScript quelconque
 */
;(function () {
  // etc.
})()

Cette façon de faire est une astuce pour éviter les problèmes lorsque deux fichiers sont rassemblés et concaténés en un seul fichier.

Sans ce point virgule, la concaténation de deux fichiers pourrait former le code JavaScript suivant :

/**
 * Librairie JavaScript quelconque n'utilisant pas les points-virgules
 */
(function () {
  // Code librairie A
})()

/**
 * Librairie JavaScript quelconque
 */
(function () {
  // Code librairie B
})()

On se retrouverait à nouveau avec la même erreur que précédemment :

(function () {
^
TypeError: (intermediate value)(...) is not a function

Par conséquent pour éviter tout problème, on ajoute un point-virgule au début de l’IIFE.

Voilà vous savez tout et vous pourrez briller dans les soirées mondaines de développeurs JavaScript ;-).

Qu’en disent les experts / développeurs connus ?

J’ai trié sur le volet quelques personnalités connues dans le monde du JavaScript pour savoir s’ils utilisaient ou pas les points-virgules.

Ceux qui utilisent les points-virgules :

  • Brendan Eich (créateur du langage JavaScript)
  • Douglas Crockford (auteur du livre JavaScript: The Good Parts)
  • Wes Bos (formateur JavaScript & FrontEnd très populaire) : il utilise les points-virgules dans tous ces cours.
  • Eric Elliott (personnalité dans le monde de la programmation fonctionnelle et des bonnes pratiques, formateur JavaScript). Il utilise les points-virgules dans tous ses exemples et son code source sur GitHub.
  • Kyle Simpson (auteur de la série de livres You Don’t Know JS)
  • David Flanagan (auteur de JavaScript: The Definitive Guide)
  • Google et AirBnB (cf leur guide de style de code pour JavaScript, ici et )

Ceux qui n’utilisent pas les points-virgules :

  • Isaac Z. Schlueter (créateur de NPM, contributeur à NodeJS)
  • Kent C. Dodds (membre du TC39, ingénieur à PayPal)
  • et sûrement d’autres !

Je pense qu’il y en a plein d’autres qui ne mettent pas les points-virgules car GitHub regorge de librairies qui sont écrites en JavaScript sans points-virgules…

Néanmoins la majorité des gens avec de l’expérience les utilisent. Je pense que c’est une forme de programmation défensive, c’est-à-dire que par anticipation pour d’éventuels problèmes, on préfère les indiquer.

Si vous décidez de ne pas mettre les points-virgules : suivez ces 3 règles !

Comme vous le savez, je n’ai rien contre un style de programmation ou un autre. Alors si vous ne souhaitez pas mettre de points-virgules, voici 3 règles simples pour vous éviter tous les problèmes possibles :

  1. Préfixez toutes les lignes commençant par [ ( ` + * / - , . par un point-virgule.
  2. Utilisez les opérateurs ++ et -- sur la même ligne que leur opérande (je ne vois pas pourquoi vous ne le feriez pas de base mais bon…)
  3. Si vous avez un problème étrange, demandez-vous : est-ce que si je colle cette ligne et celle d’au dessus, une instruction valide est formée ? Si oui => mettez un point-virgule !

Des tonnes de recherches scientifiques sur la lecture rapide et sur le mouvement des yeux suggèrent qu’il est plus facile de rater un symbole à droite de la ligne qu’à gauche en début de ligne.

Par ailleurs, les adeptes de l’omission du point-virgule ne veulent souvent pas mettre de point-virgule en fin de ligne pour l’aspect esthétique de leur programme (ils trouvent ça plus joli).

Par conséquent, la convention adoptée majoritairement par ces développeurs est d’insérer les points-virgules nécessaires en début de ligne.

Dernière chose, si vous ne voulez pas mettre de point-virgule en début de ligne, il est très facile d’introduire une variable intermédiaire, par exemple :

let clavier = 'azerty'
[1,2,3].forEach(function(value){console.log(value)})

// peut être réécrit :
let clavier = 'azerty'
let unDeuxTrois = [1,2,3]
unDeuxTrois.forEach(function(value){console.log(value)})

Ce code ne générera pas d’erreurs et vous n’aurez besoin d’aucun point-virgule !

Outils pour éviter tous les problèmes (avec ou sans points-virgules)

Que vous mettiez ou pas les points-virgules, vous pouvez utiliser un outil de vérification de syntaxe qu’on appelle linter qui vous préviendra du genre de cas particuliers qu’on a vu précédemment.

Il en existe beaucoup, les plus connus sont :

Certains viennent pré-configurés et vous forcent à coder d’une certaine manière (comme JSLint et Standard JS), d’autres sont entièrement paramétrables.

Il existe également des extensions Visual Studio Code qui facilitent l’utilisation de ces outils directement depuis VSCode, voici les extensions VSCode correspondant aux outils ci-dessus :

Notez que l’extension ESLint permet d’intégrer n’importe quel autre linter facilement, c’est pourquoi c’est la plus populaire sur VSCode.

Le mot de la fin

Que vous utilisiez les points-virgules ou pas, il est important de rester cohérent dans votre façon de programmer. Si vous les utilisez, mettez-les partout ou c’est nécessaire, sinon ne les mettez nulle part.

Dernier point, arrêtez de perdre votre temps dans des discussions sans fin sur s’il faut mettre ou pas des points-virgules.

Le seul moment où ces discussions sont utiles, c’est si vous travaillez en équipe ou que vous utilisez des outils spécifiques sensibles aux points-virgules dans du code JavaScript.

Autrement, c’est une préférence personnelle.

Sources supplémentaires de lecture (en anglais)

Si vous voulez en savoir plus et lire les commentaires acides des 2 camps, faites vous plaisir :

Quel langage de programmation choisir en 2019 ?

Il existe beaucoup de langages de programmation… tellement à vrai dire, qu’il en existe au moins un pour chaque lettre de l’alphabet !

Les plus connus sont le JavaScript, Java, Python, C#, PHP, C/C++, Ruby, Swift et l’Objective-C.

Quand on est débutant il est difficile de choisir son premier langage. On a peur de « prendre le mauvais ».

Dans cet article je vais vous expliquer les critères à prendre en compte pour choisir son premier langage quand on est débutant en programmation.

Enfin, vous découvrirez pourquoi je conseille d’apprendre le JavaScript comme premier langage de programmation.

Vidéo complémentaire de cet article

Introduction

Vous êtes débutant et vous vous posez la toute première question que tous les débutants se posent : quel langage de programmation choisir pour apprendre à programmer ?

Deux possibilités :

  1. Soit vous savez déjà ce que vous voulez programmer : une application mobile, un site web, un jeu vidéo, une application de bureau etc.
  2. Soit vous ne savez pas trop… mais vous savez que vous voulez apprendre à programmer !

Dans les deux cas, les prochains critères sont applicables.

Manifeste pour l’enseignement du JavaScript

J’ai un unique but :

Aider les gens n’ayant aucune expérience en programmation et qui souhaitent changer de métier à apprendre le JavaScript et à se faire embaucher en tant que développeur le plus vite possible.

Pour atteindre cet objectif :

  • Je suis en train de créer JavaScript de Zéro: une formation vidéo en ligne qui vous apprendra suffisamment de JavaScript pour être embauché rapidement. Vous êtes en train de lire le manifeste de cette formation. Accédez en avant-première à JavaScript de Zéro.
  • Je publie chaque vendredi une nouvelle leçon en vidéo sur JavaScript.
  • Je tweete des liens et des bouts de code utiles pour améliorer votre productivité en JavaScript.

Pourquoi créer une formation vidéo sur JavaScript alors qu’il en existe déjà beaucoup ?

Parce que celles qui existent déjà n’enseignent pas certains points cruciaux

Les concepts en premier, la syntaxe en second

Toutes les formations pour débutants focalisent sur l’enseignement de la syntaxe JavaScript avant de vous expliquer les concepts de programmation sous-jacents. Quelle approche compliquée pour les débutants !

J’utiliserai des animations graphiques pour expliquer en Français clair et sans utiliser de code les concepts de programmation dans un premier temps. Ensuite seulement, vous apprendrez comment appliquer ces concepts en utilisant le langage JavaScript.

Comment résoudre les bugs par soi-même

C’est LA compétence la plus importante à acquérir pour un développeur professionnel. Et pourtant, la plupart des formations (pour ne pas dire toutes) n’enseignent jamais comment résoudre les bugs, interpréter les messages d’erreur, utiliser le débogueur ou chercher sur Google des réponses.

Malheureusement pour vous, c’est 90% du travail d’un développeur !