Compilateur et commentaires

1. Compilateur C#

L’ordi ne comprend pas le langage humain. Il ne pige même pas les langages de programmation. Il ne comprend que des programmes écrits en code machine — c’est-à-dire des suites de zéros et de uns.

Pour les chiens, il y a des ordres comme « Au pied », « Donne la patte » et d’autres, et quand ils les entendent, ils font un truc important. Pour l’ordi, ce sont des nombres qui jouent ce rôle : chaque commande est codée par un certain nombre (on appelle ça aussi code machine).

Écrire un programme sous forme de nombres, c’est super galère, donc les humains ont inventé les langages de programmation et les compilateurs. Un tel langage, d’un côté, il est compréhensible pour l’humain, de l’autre — pour le compilateur. Le compilateur, c’est un programme spécial qui traduit le texte du programme écrit dans un langage de programmation en un ensemble de codes machine.

En général, le dev écrit son programme dans un langage de programmation, puis il lance le compilateur, qui, à partir des fichiers écrits par le dev, crée un fichier unique avec le code machine — le programme final (compilé).

Le programme obtenu peut être exécuté direct sur l’ordi. Le souci, c’est que le code du programme dépend beaucoup du processeur et du système d’exploitation. Un programme compilé pour Windows ne marchera pas sur un téléphone Android.

Si tu as écrit un programme pour Android, alors sur le système d’exploitation Windows il ne se lancera pas !

Mais avec C#, c’est beaucoup plus innovant.

Le compilateur C# ne compile pas toutes les classes en un seul programme en code machine. À la place, il compile ton code non pas en code machine, mais en un code spécial intermédiaire IL (byte-code). La compilation en code machine se fait au lancement du programme.

Mais alors, qui compile le programme en code machine au moment où il démarre ?

Pour ça, il y a un programme spécial appelé CLR (Common Language Runtime) — la machine virtuelle C#. D’abord tu lances le CLR, puis le programme qui contient le byte-code. Et c’est le CLR qui, juste avant d’exécuter le programme, le compile en code machine.

Si tu as un processeur de ouf qui supporte plus d’instructions machine, alors pendant la « deuxième compilation », le code machine généré sera optimisé pour ton processeur et ton OS. C’est pour ça que C# est parfois plus rapide que C++, qui est compilé direct en code machine et ne peut utiliser que les instructions processeur les plus répandues.

2. Erreurs typiques à la compilation

La vitesse et l’optimisation du code, pour l’instant, on s’en fiche un peu, mais ce qui est super important, c’est que le compilateur vérifie ton programme pour les erreurs. Il vérifie si le code est correct et il ne te laissera pas aller plus loin s’il trouve ne serait-ce qu’une petite erreur.

Exemple d’erreur :

Tu essaies d’assigner un nombre à une variable qui ne peut contenir que du texte.

string userName = 42; // Oups ! Ça ne marche pas comme ça.

Le compilateur va direct te sortir une erreur de type : "Cannot implicitly convert type 'int' to 'string'".

Autre exemple — une faute de frappe dans la commande WriteLine() :

Console.WriteLin("Salut !"); // Erreur dans le nom de la méthode

Le compilateur dira : "Cette méthode n’existe pas — vérifie ta syntaxe !"

Comment lire les erreurs ?

La plupart des compilateurs te disent où est l’erreur dans le code, et parfois ils proposent même des solutions. N’aie pas peur des erreurs : chacune d’elles, c’est un pas vers l’illumination et la victoire sur ton « boss » intérieur.

3. Commentaires

Alors, imagine : tu écris un programme compliqué. Tout marche, t’es un génie ! Mais un mois plus tard, tu rouvres ce fameux code et... tu captes plus rien. Deux lignes de code ici, une variable chelou là. Dans ta tête : « C’est sûr, c’est pas moi qui ai écrit ça ! ». C’est là que les commentaires te sauvent la vie.

Les commentaires, c’est comme des post-its dans un bouquin ou des notes sur le frigo ("Bière. Ne pas boire. Pour demain !"). Le compilateur les ignore, mais les humains, non. Les commentaires servent à expliquer le sens du code, à marquer des détails importants et même à « désactiver » des bouts de programme sans les supprimer.

Important : Aucun compilateur ne lit tes commentaires, ils sont totalement ignorés !

Commentaires sur une ligne

En C#, il y a deux types de commentaires — sur une ligne et sur plusieurs lignes. Les commentaires sur une ligne commencent par deux slashs // et vont jusqu’à la fin de la ligne. Tout ce qui suit // est considéré comme un commentaire et est totalement ignoré par le compilateur.

Exemple :

Console.WriteLine("Salut, monde !"); 	// Ça affiche un message de bienvenue à l’écran

Là, // Ça affiche un message de bienvenue à l’écran — c’est un commentaire. Si une ligne de code n’est pas claire, écris un commentaire comme ça !

Encore un exemple :

int x = 42; 	// L’âge du développeur

Tu peux aussi écrire des commentaires sur une ligne entière :

// Initialisation de la variable avec le nom de l’utilisateur
string userName = "John";

C’est presque comme des répliques dans un script : le commentaire explique le pourquoi du comment.

Commentaires sur plusieurs lignes

Et si t’as plein de trucs à dire ? Une vraie histoire ? Pour ça, il y a les commentaires sur plusieurs lignes, qui commencent par /* et se terminent par */. Tout ce qu’il y a entre ces symboles est ignoré par le compilateur, même si ça fait plusieurs lignes.

Exemple :

/*
  Ici, on affiche le nom de l’utilisateur à l’écran.
  Si le nom est absent, on écrit "Invité".
*/
Console.WriteLine("Entrez votre nom :");

Ou comme ça :

int age = 18; /* Valeur initiale de l’âge
                 pour un nouvel utilisateur */

Attention : tu ne peux pas imbriquer des commentaires sur plusieurs lignes. N’essaie pas d’être plus malin que le compilateur — ça ne marchera pas.

Illustration :

4. Exemples de la vraie vie

« Désactiver » une ligne de code :

Parfois, tu veux juste ne pas exécuter un bout de code temporairement. Les commentaires sont parfaits pour ça :

// Console.WriteLine("Texte temporairement inutile");

La ligne reste, mais le compilateur ne la « voit » pas.

Notes TODO et FIXME

Les devs sont humains aussi, et parfois il faut se rappeler que le code n’est pas fini, ou qu’il y a un bug ici. Pour ça, on écrit souvent :

// TODO : faire une vérification pour l’entrée vide
// FIXME : cette fonction calcule mal la somme

Plein d’éditeurs et d’IDE mettent même ces mots en évidence !

Les devs ont de l’humour

Et bien sûr, parfois, on tombe sur des commentaires vraiment marrants dans le code :

// Je ne suis pas responsable de ce code. On m’a forcé à l’écrire contre ma volonté.

// Cher, je_suis_du_futur ! S’il te plaît, pardonne-moi pour ce code.
// Si je revois encore un truc comme ça, je vais devoir venir au boulot armé.
// Si jamais cette condition se réalise, préviens-moi au tél. xxx-xxx-xxx pour une récompense.

// Cher développeur :
//
// Quand tu auras fini « d’optimiser » cette sous-routine
// et que tu réaliseras à quel point c’était une grosse erreur,
// s’il te plaît, augmente le compteur ci-dessous comme avertissement
// pour le prochain gars :
//
// nombre_d’heures_passées_ici = 42

// Quand j’ai commencé à écrire ça, seul Dieu et moi savions ce que je faisais.
// Maintenant, il ne reste plus que Dieu

// Parfois, j’ai l’impression que le compilateur ignore tous mes commentaires

// Je dédie tout mon code, tout mon travail à ma femme Darlene, qui
// devra subvenir à mes besoins, à ceux de nos trois enfants et du chien, quand
// ça partira en prod.

Ouais, les commentaires peuvent être très drôles. Après tout, c’est des humains qui les écrivent.