On a vu dès le chapitre C1‑I  que la lisibilité des programmes est un enjeu décisif du génie logiciel – cf. le livre Clean Code: a handbook of agile software craftsmanship qui est entièrement consacré à cette question, et dont il existe une version française (Coder proprement). Le respect de l'exigence de lisibilité du code tient avant tout à l'observance de bonnes pratiques générales, certaines ayant déjà été proposées dans divers chapitres de cette partie C2 du cours, par exemple au chap. C2‑III pour la déclaration des constantes .

Mais ce qu'on appelle « bonne pratique » peut varier d'une période, d'un langage ou d'un contexte professionnel à l'autre (entreprise, laboratoire de recherche, équipe…). Très souvent, un chef de projet informatique impose à son équipe de développement une convention de codage W, c'est‑à‑dire un ensemble de règles et de recommandations à respecter, pour notamment :

• prévenir des erreurs classiques grâce à des obligations et des interdictions formelles (par exemple, pas de goto…) ;
• garantir l'homogénéité du code, dont la production est nécessairement répartie entre plusieurs codeurs, et ainsi faciliter sa relecture ainsi que la coordination du projet.

Néanmoins, pour un codeur débutant à qui l'on demande de composer des programmes courts et très simples comme ceux des premiers exercices et travaux pratiques de ce module de formation, il est difficile de comprendre l'importance des conventions de codage. Souvent perçues comme inutilement contraignantes, ces dernières semblent pénaliser l'effort intellectuel nécessaire pour concevoir les solutions aux problèmes posés.

Il faut pourtant y accorder la plus grande attention pour adopter dès le début de bonnes habitudes. Elles prendront tout leur sens au fur et à mesure de l'apprentissage individuel (ne serait‑ce que pour pouvoir relire son propre code plus facilement) puis dans le cadre d'un travail d'équipe.

Sans prétention d'exhaustivité, les recommandations de ce chapitre se concentrent sur les premiers détails auquel tout codeur est confronté au début de son apprentissage :

• choisir des identificateurs de données ou de fonctions,
• rédiger des commentaires,
• indenter et espacer les éléments de code…

D'autres aspects importants pour la lisibilité – la décomposition en fonctions, le choix des algorithmes et des structures de données – seront abordés au fur et à mesure des chapitres, avec un repérage explicite, comme cela a déjà été fait dans les chapitres précédents.

Pour une présentation plus détaillée, on pourra consulter le guide  rédigé et gratuitement distribué par l'ANSSI (Agence nationale de la sécurité des systèmes d'information W), en gardant toutefois à l'esprit qu'en matière de bonnes pratiques, personne ne détient de vérité absolue – même une agence nationale.

Les identificateurs

Ces règles sont respectivement détaillées dans les trois sections qui suivent.

Tout en anglais

Dans un code source, quel que soit le langage de programmation, le recours exclusif à l'anglais (GB ou US) pour nommer les identificateurs est vivement recommandé car il présente plusieurs avantages décisifs sur toute autre langue.

• En premier lieu, il y a l'homogénéité linguistique car, sauf exception, quel que soit le langage de programmation, tous les mots‑clefs, les noms de types et les identificateurs de fonctions standards sont déjà issus de l'anglais. Si le codeur forme aussi ses identificateurs en anglais, le code peut former des instructions très semblables à des phrases dans cette langue.


Pour un programme de simulation de lancers d'un dé à 6 faces, le code ci‑dessous est rendu particulièrement lisible grâce à l'emploi d'identificateurs explicites en anglais  :
while (randomNumber == previousDisplayedNumber) {…
En effet, avec le mot‑clef while forcément en anglais l'instruction se lit presque mot‑à‑mot comme le début d'une phrase en langage naturel :
« While the random number equals the previous displayed number… »

• Un deuxième aspect important est la concision des termes car les mots en anglais sont, en règle générale, plus courts en anglais que dans la plupart des autres langues – notamment le français.


En prolongement de l'exemple précédent d'un programme de simulation de lancers d'un dé à 6 faces, observons l'identificateur anglais :
randomNumber
Il fait 3 lettres de moins que son équivalent en français :
nombreAleatoire

Ce gain de longueur de 25 % n'est pas négligeable. Il devient d'autant plus sensible lorsqu'on emploie l'identificateur dans une expression un peu élaborée, au point de nécessiter parfois des sauts de lignes indésirables.

• Un autre atout de l'anglais est l'absence de caractères diacritiques (lettres accentuées, etc.) qui sont non conformes aux restrictions de codage des identificateurs (cf chap. C2‑II . Avec une langue assez accentuée comme le français, on s'expose à des risques de confusion sur le sens des identificateurs choisis.


En prolongement de l'exemple précédent d'un programme de simulation de lancers d'un dé à 6 faces, considérons maintenant l'identificateur anglais :
previousDisplayedNumber

Son équivalent en français le plus direct est :
precedentNombreAffiche (sans accents)
où :

• le premier mot precedent peut être interprété de deux façons :
• comme « précédent » (adjectif) – c'est ce que l'on veut dire ici ;
• mais aussi comme « précèdent » (forme conjuguée).
• le dernier mot affiche peut aussi être interprété de deux façons :
• comme « affiché » (participe passé)  c'est ce que l'on veut dire ici ;
• ou encore comme « affiche » (le nom).

Ces multiples possibilités font que, lors d'une première lecture, le sens de l'identificateur français « ne saute pas immédiatement aux yeux ».

• Enfin, il faut aussi prendre en compte l'universalité linguistique dans le cadre d'équipes internationales de développement, où tout le monde parle anglais – ce qui est rarement le cas pour d'autres langues.

Des identificateurs explicites

La précision avec laquelle un identificateur décrit son objet résulte d'un compromis :

• Elle doit être suffisante pour rendre intelligibles le sens des instructions dès leur première lecture.
En règle générale, les abréviations et les sigles sont à éviter – sauf ceux de la langue technique courante comme, par exemple rpm, mph, pwm, etc.

Pour nommer une variable qui mémorise le niveau logique de tension sur une entrée du port numérique d'une carte Arduino à laquelle un bouton‑poussoir est relié :
• Les identificateurs b, pb ou push_b sont à bannir car ce sont abréviations non universelles, ici beaucoup trop courtes, donc pas claires.
• Les identificateurs button ou pushButton ne sont pas assez explicites, car ils omettent de préciser que l'objet désigné est un niveau logique de tension – aspect matériel très important.
Mais il pourrait néanmoins convenir si l'on prenait la précaution de renommer les pseudo‑constantes de niveaux de tension HIGH et LOW par d'autres comme IDLE et PUSHED. On pourrait alors coder un test conditionnel très lisible comme, par exemple :
if (button == PUSHED)

• Les identificateurs buttonLevel ou pushButtonLevel conviennent, le premier ayant l'avantage de la concision. Son manque de précision sur le type du bouton (poussoir, tournant, tactile, etc.) n'a pas d'impact en termes de compréhension dès lors que cet aspect n'est pas déterminant pour la compréhension du code. Avec ce choix, un test conditionnel comme par exemple :
  if (buttonLevel == HIGH)
  est parfaitement compréhensible. C'est donc la solution le plus souvent retenue.
• Mais il faut que la précision ne soit pas excessive, car plus les identificateurs sont longs, plus les instructions sont pénibles à lire et même à formater (on est amené parfois à devoir insérer des saut de lignes indésirables).


1. Dans l'exemple précédent d'une variable qui mémorise le niveau logique de tension sur une entrée du port numérique d'une carte à microcontrôleur à laquelle un bouton‑poussoir, l'identificateur :
   pushButtonLogicalVoltageLevel
   est certes plus précis mais en contre‑partie, il alourdit considérablement le code, sans grande utilité.

2. Dans un programme de contrôle commande de moteur à courant continu, pour ajuster la fréquence de modulation de largeur d'impulsion sur la grille d'un transistor MOSFET à canal N, il est utile de déclarer :
• un identificateur de constante comme par exemple :
  NMOS_TRANSISTOR_GATE_PIN
  pour désigner la grille du transistor (gate en anglais) ;
• un identificateur de variable comme par exemple :
  pwmFrequency
  pour désigner la fréquence de modulation ;
On peut alors coder de façon très lisible un appel de fonction du framework Arduino comme :
analogWriteFrequency(NMOS_TRANSISTOR_GATE_PIN, pwmFrequency);
Une telle instruction est déjà bien longue, mais elle dépasserait les 100 caractères si, dans l'identificateur de la variable, on avait utilisé :
• pulseWidthModulation à la place de pwm,
• NEGATIVE_CHANNEL_METAL_OXYDE_SEMICONDUCTOR à la place de NMOS.

Une typographie optimisée

Usage du tiret‑bas : le style « snake case »

En langages C et C++, le tiret‑bas _ est le seul caractère symbolique autorisé dans les identificateurs. Il est tentant de l'employer pour simuler un espace et ainsi former des identificateurs composés de plusieurs mots, comme par exemple push_button_level.

Ce style de typographie porte le nom de « snake case » W, parce que la succession des mots et des tirets peut faire penser à un serpent. Son principal avantage est qu'elle facilite grandement la lecture des identificateurs par le fait que les mots qui le composent se détachent bien les uns des autres.

La typographie « snake case » est utilisée à divers endroits de la bibliothèque standard du C++, par exemple dans le fichier d'en‑tête random, où l'on trouve notamment les classes de moteurs de génération de nombres aléatoires suivantes C++ :

• linear_congruential_engine,
• mersenne_twister_engine,
• subtract_with_carry_engine…

Ce choix est particulèrement bien venu ici pour des identificateurs déjà assez complexes.

Toutefois, par rapport au « camel case » (cf. ci‑après), le style snake case présente l'inconvénient qu'il allonge un peu les identificateurs.

Mots compactés : le style « camel case »

Pour ne pas recourir au tiret‑bas, une solution typographique très répandue pour former un identificateur consiste à commencer chaque mot qui le compose par une lettre majuscule, comme par exemple : pushButtonLevel.

Ce style de typographie est appelé « camel case » W parce que les majuscules au début de chaque mot peuvent faire penser aux bosses d'un chameau. Elle produit des identificateurs plus compacts mais un peu moins lisibles qu'en « snake case ».

Dans le framework Arduino, c'est surtout la typographie « camel case » qui est employée. Pour s'en convaincre, il suffit de jeter un œil au fichier d'en‑tête principal arduino.h avec, aux lignes nº 104 et suivantes, des exemples remarquables :

• clockCyclesPerMicrosecond,
• clockCyclesToMicroseconds,
• microsecondsToClockCycles…

Attention, le style « camel case » présente quelques subtilités.

Il est d'usage courant de donner presque le même identificateur pour désigner une unique variable d'un type défini par le codeur et le type lui‑même. Dans un tel cas, ils se distinguent uniquement par le fait que :

• l'identificateur du type prend une majuscule initiale ;
• l'identificateur de la variable prend une minuscule initiale.

Par exemple, dans le cadre d'un programme académique de jeu de Puissance 4 recodé en langage C++ avec les concepts de la programmation orientée objet (cf. chap. C2‑VI ), on déclare un seul objet nommé connect4board de la classe Connect4board – donc avec presque le même identificateur sauf pour la majuscule initiale « C » :

  Connect4board connect4board;

Dans l'identificateur d'une variable qui mémorise la couleur d'une LED à technologie RGB (cf. le sujet de TP. C3‑2 ), comme par exemple :
middleLEDColor
il est difficile de lire la transition entre les mots LED et Color. On pourrait alors être tenté de coder plutôt :
middleLEDcolor
mais ce n'est pas la pratique courante. La solution usuelle consiste plutôt à coder le sigle LED en minuscules pour retrouver une typographie « camel case » classique, comme ci‑dessous :
middleLedColor

La règle nº 1 énoncée supra qui consiste à ne jamais employer une majuscule initiale pour un identificateur de donnée prime aussi sur la convention générale d'employer des majuscules pour les sigles.

En effet, la présence d'une majuscule initiale dans un identificateur est automatiquement détectée par de nombreux éditeurs de code, qui assimilent alors l'identificateur à celui d'un type ou d'une classe et lui confère alors le style spécifique réservé à cette catégorie syntaxique (selon les réglages par défaut ou choisis).

Exemple. Observons la mise en forme automatique opérée dans sur cette présente page web par le script Code Prettify (cf. infra ) sur les deux identificateurs déclarés ci‑dessous pour une variable censée mémoriser l'état éteint ou allumé d'une LED (sigle anglais pour light emitting diode) :

int ledState = 1; // OK
int LEDstate = 1; // NOT OK! Data identifier detected as a type name

• La ligne n° 10 ne pose pas de problème puisque, avec sa minuscule initiale, ledState est bien détecté comme une identificateur de donnée.
• En revanche, à la ligne n° 11, à cause de la majuscule initiale, LEDstate est détecté comme un identificateur de type, et affiché en italique vert, comme le descripteur int, ce qui n'est pas satisfaisant puisqu'il s'agit d'une donnée, et non pas d'un type.

Identificateurs en majuscules

Les conventions d'emploi des majuscules et de la typographie « snake case » pour les identificateurs de constantes sont bien celles employées dans le framework Arduino : souvenons‑nous de LOW, HIGH, INPUT, INPUT_PULLUP, LED_BUILTIN, etc. (cf. chap. C2‑VIII ).

Les commentaires

Parce qu'ils ne sont pas du code et qu'ils sont potentiellement très divers, les commentaires ne peuvent faire l'objet que de règles informelles. Au delà des aspects purement syntaxiques qui ont été présentés au chapitre C2‑II , une manière d'aborder cet aspect non normalisé de la programmation consiste à suivre un questionnement analytique classique :
Pourquoi ?  Où ?  Comment ?

Pourquoi ?

En pratique, il est recommandé d' ajouter des commentaires pour préciser ponctuellement  :

• les unités des valeurs numériques lorsqu'elles ne sont pas évidentes ;


Dans les programmes pour carte à microcontrôleur, les calculs mis en œuvre font souvent appel à de nombreuses unités de mesure. Mais les instructions du programme ne manipulent que des données numériques et les unités de mesure restent implicites, ce qui ne facilite pas la compréhension des instructions.



Par exemple, on emploie généralement deux unités de temps, la milliseconde ou la microseconde. Dans la déclaration d'un donnée temporelle, il est pertinent indiquer l'unité qui est implicitement choisie, comme par exemple dans le commentaire de fin de ligne ci‑dessous :

  const int CYCLE_DURATION = 20000; // microseconds

En effet, l'interprétation de la valeur de cette variable ne peut se faire qu'à la lecture des expressions qui l'utilisent (comme par exemple un appel de la fonction delayMicroseconds), et qui peut être codées bien plus loin dans le fichier.

• les calculs complexes pour lesquels une brève explication ou une confirmation facilite la lecture du code ;


Dans les programmes pour carte à microcontrôleur, lorsqu'on emploie un capteur, on effectue des calculs spécifiques à ce dernier (on applique sa fonction de transfert). Sans explications, le code qui implémente ces calculs reste difficile à comprendre.



Par exemple, le commentaire ajouté ci‑dessous en ligne nº 10 détaille la formule d'interprétation de la valeur de tension aux bornes d'un capteur de courant, qui est reliée à une broche du port analogique d'une carte à microcontrôleur.

  // current sensor : 0.1 V/A around 2.5 V
  batteryDischargeAmp = (2.5 - (analogRead(ampSensorPin) * 2.5 / 1024.0)) / 0.1;

Cette formule est indispensable pour pouvoir comprendre à la ligne nº 11 le calcul de la variable qui mémorise le courant de décharge d'une pile.

• les précautions à prendre, notamment en vue d'éventuelles futures modifications du programme ; 


Dans les programmes pour carte à microcontrôleur, on est parfois amené à ajouter des composants au fur et à mesure de l'évolution d'un projet, et donc à éventuellement devoir modifier le câblage. Si le bon fonctionnement du programme répond à des contraintes de broches, il est nécessaire de les préciser.



Par exemple, dans un programme qui utilise un capteur de température (Dallas DS18B20 – cf. sujet de TP P3‑1 ), il est possible de brancher directement le connecteur à trois broches du capteur directement sur le port numérique d'une carte Arduino, à condition de faire jouer à la broche nº 13 le rôle de VCC. Les commentaires de fin de ligne apportent cette précision bienvenue dans le code ci‑dessous :

const int SENSOR_VCC_PIN = 13; // will be constantly set to HIGH -> VCC
const int SENSOR_DAT_PIN = 12; // Grouped 3-pin connector GND-VCC-DAT

• et aussi le sens de tout élément de code contre‑intuitif.


On a vu au chapitre C2‑IX  qu'il était opportun de rajouter une pause artificielle (appel de la fonction delay) pour fluidifier la simulation d'un programme Arduino dans l'environnement Tinkercad.

Dans un programme qui se veut réactif, donc où le recours à une fonction comme delay est a priori « proscrit », le rôle spécifique de cette pause artificielle doit être précisé en commentaire, comme par exemple ci‑dessous :

  delay(10); // only for a quicker Tinkercad simulation

Ainsi, tout lecteur du code comprend immédiatement que cette pause peut être supprimée ou mise en commentaire dans un contexte d'exécution sur une vraie carte.

Où ?

• Les premières lignes du fichier sont toujours réservées à l'en‑tête descriptif du programme, qui doit impérativement préciser toutes les données nécessaires à la compréhension globale du code : objet, matériel mis en œuvre, algorithme, version, etc.


Dans un programme pour carte Arduino de commande d'une LED par un bouton (cf. le sujet de TP C2‑1 ), pour décrire le montage et les spécification du fonctionnement attendu, on pourrait saisir le commentaire d'en‑tête suivant :

/* * * * * * * * * * LED-BUTTON COMMAND PROGRAM * * * * * * * * * *
 *  BOARD: any Arduino board
 *  LED: builtin LED
 *  BUTTON: push button on D8 pin with pull-down 2k resistor (positive logic)
 *  COMMAND: on/off LED on rising edge of push button signal
 */

• Une ligne au dessus ou dessous d'une fonction, d'un bloc ou même d'un groupe d'instructions peut être employée pour en décrire l'objectif ou se repérer au premier d'œil dans le code.


Dans un programme pour carte Arduino de compte à rebours (cf. TP C4‑2 ), la fonction loop finit par s'étendre sur plus de 60 lignes de code, ce qui dépasser la capacité d'affichage vertical d'un moniteur. Il devient alors difficile d'avoir une vision d'ensemble du programme.

Une ligne de commentaires au dessus de chaque bloc est alors bien utile pour préciser le rôle de chacun, comme par exemple ci‑dessous.

  // state changes
  if (mode == WORK) {
    if (risingEdge(startStopButtonSignal)) {
      state = State (!bool(state));
    }
    if (remainingSeconds == 0) {
      state = STOP;
    }
  }

• Une fin de ligne est aussi un bon emplacement pour un commentaire ponctuel relatif à une instruction ; si la ligne de code est longue, on peut placer le commentaire au dessus ou au dessous, en dernier recours.


Dans le même programme de compte à rebours, on a ajouté un commentaire de fin de ligne (nº 50) pour apporter une précision sur l'usage du type de données énumérées State.

enum Mode  : uint8_t {WORK, SET};
enum State : uint8_t {STOP, RUN}; // in mode WORK only

Le lecteur peut alors comprendre sans peine que les valeurs STOP et RUN ne sont valables que lorsque le système est dans le mode WORK.

Quand ?

Dans la pratique, commenter le code est vu au mieux comme une corvée nécessaire, au pire une activité nuisible à la concentration qui est requise pour le codage proprement dit.

Lors de la mise au point d'un programme, alors qu'on ne cesse de changer ses instructions, on se demande bien à quoi bon commenter, s'il faut ensuite perdre du temps à tout effacer. Procrastiner (remettre au lendemain ce qu'on devrait faire le jour même) est un défaut banal, surtout si l'on a le commentaire bavard…

Comment ?

Comme les identifiants, et pour des mêmes raisons – homogénéité du texte, concision des termes, universalité linguistique – il est préférable d'exprimer les commentaires tout en anglais, et ce même si l'éditeur de code est paramétré pour afficher les caractères accentués.

Le format du code

Alignement et indentation

Contrairement à une police dite « proportionnelle » comme Cambria (cf. ci‑contre), une police à chasse fixe comme Consolas, Courrier new, Source Code Pro, etc. permet une indentation régulière des lignes de code, c'est‑à‑dire un décalage horizontal vers la droite du début de l'instruction d'un ou plusieurs caractères espace ou mieux, de tabulation.

Partant du principe général qu'on saisit une ligne de code par instruction simple (ou par directive), l'indentation évolue au fur et à mesure des instructions selon les structures de contrôles employées :

• l'indentation est augmentée à chaque « entrée » dans un bloc et diminuée d'autant à chaque « sortie » de bloc ; toutes les lignes du bloc ayant la même indentation, elles sont donc alignées verticalement, à gauche) ;
• quant aux accolades de blocs, elles peuvent être positionnées de deux manières :
• soit l'une et l'autre en début de ligne, afin qu'elles soient alignées verticalement,
• soit l'accolade ouvrante { en fin de ligne et l'accolade fermante } en fin de ligne, alignée avec le mot-clef de la structure de contrôle.

Ces bonnes pratiques permettent de repérer au premier coup d'œil, par l'alignement des lignes de code, les blocs des structures de contrôle.

if (condition)
{
  instruction;
  ⫶
  while (condition)
  {
    instruction;
    ⫶
    instruction;
  }
  instruction;
}
else
{
  instruction;
  ⫶
  instruction;
}

if (condition) {
  instruction;
  ⫶
  while (condition) {
    instruction;
    ⫶
    instruction;
  }
  instruction;
}
else {
  instruction;
  ⫶
  instruction;
}

Emploi de la touche tabulation

Pour maîtriser la régularité de l'indentation, on peut recourir à la touche de tabulation horizontale  TAB qui, en principe, insère dans le texte à chaque appui un caractère HT (horizontal tabulation, code ASCII 0x09).

Avec la plupart des éditeurs de code, en sélectionnant un groupe de lignes de code, on peut le décaler d'une tabulation :

• vers la droite en appuyant sur la touche TAB ;
• vers la gauche en appuyant simultanément sur les touches ⇧TAB ;

De plus, la plupart des éditeurs de code possèdent une fonction d'auto-indentation d'une partie de code sélectionnée.

Dans Sublime Text, on trouve ces fonctionnalités (et bien d'autres) via le menu Edit/Line (cf. la figure ci‑contre).

Valeur de l'unité d'indentation

Sur la plupart des éditeurs de code, il est possible de régler la taille de la tabulation en nombre de caractères espaces équivalents :

• une grande valeur – typiquement 4 espaces, voire plus – met bien en évidence l'imbrication des blocs mais elle consomme davantage la largeur de ligne disponible qui est limitée par celle de la fenêtre d'affichage, et en définitive, par celle du moniteur ;
• aussi, pour éviter les débordements de la fenêtre ou les retours à la ligne intempestifs, il est préférable de choisir une petite valeur en fixant la tabulation à 2 espaces seulement ; c'est valeur minimale recommandée car en dessous, l'indentation étant à peine visible, elle ne remplit plus sa fonction.

De plus, il est également possible de convertir automatiquement dans le fichier source tous les espaces en tabulations, et vice‑versa.

Sur Sublime Text, on accède à ces réglages et fonctionnalités via le menu View/Indentation, ou encore en cliquant sur la zone Tab Size dans la barre d'état tout en bas de la fenêtre pour faire apparaître un menu déroulant et choisir la valeur d'une tabulation (cf. la figure ci‑contre).

Reprenons l'exemple ci‑dessous et comparons le code générique indenté par tabulations de deux espaces (code de gauche) et quatre espaces (code de droite) :

if (condition) {
  instruction;
  ⫶
  while (condition) {
    instruction;
    ⫶
    instruction;
  }
  instruction;
}

if (condition) {
    instruction;
    ⫶
    while (condition) {
        instruction;
        ⫶
        instruction;
    }
    instruction;
}

Ici, on pourrait facilement préférer l'indentation à quatre espaces, parce que les conditions et instructions génériques forment des motifs très courts. Mais en pratique, c'est rarement le cas…

Aération horizontale et verticale

À l'exception des codes composés en réponse à des petits exercices académiques, les programmes sources deviennent vite très complexes. Leur lecture peut devenir très pénible s'ils sont présentés de façon trop compacte.

Aération horizontale

Aération verticale

/* Program that calculate the number of days in the month of a given date
*/
#include <stdio.h>
#include <stdbool.h>
 
int main(void)
{
  printf("Type a date with format mm/yyyy (mm = 0 to quit)\n");
  int month = 0, year = 0;


  while (true) {    
    int  daysInMonth = 0;
    bool leapYear = false;
    
    // scan and check the date typed by the user
    printf("> ");
    scanf(" %d/%d", &month, &year);
    if (month == 0) break;
    if (month < 0 || month > 12) {
      printf("Month is out of range!\n");
      continue;
    }

    // check if the year is a leap year
    if ((year % 4 == 0 && year % 100 != 0) || year % 400 == 0) {
      leapYear = true;
    }
    else {
      leapYear = false;
    }
    
    // calculate and display the number of days in the month
    switch (month) {
      case 2 :                // February
        if (leapYear) {
          daysInMonth = 29;
        }
        else {
          daysInMonth = 28;
        }
        break;
      case 4 : case 6 : case 9 : case 11 :
        daysInMonth = 30;
        break;
      default :  
        daysInMonth = 31;
    }
    printf("Number of days in the month: %d\n\n", daysInMonth);
  } // while(true)

  
  printf("Goodbye.\n");
  return 0;
}

  //================================

Coloration syntaxique

Aujourd'hui, tous les éditeurs de code proposent cette fonctionnalité, car elle améliore considérablement la lisibilité du code. Il serait dommage de ne pas se l'approprier ! Car même si ce n'est pas toujours aisé pour un débutant, la mise en forme du code est paramétrable.

Ainsi, le présent site web utilise le script de coloration externe Code Prettify principalement développé en langage JavaScript/CSS par Grant Timmerman chez Google dans le cadre d'un projet open‑source, que l'on peut trouver en archive ici G. Loin d'être parfait (cf. notamment quelques problèmes signalés au chap. C5‑VI ) et non maintenu depuis 2020, il présente l'avantage d'être très simple à exploiter.

On pourrait penser que les choix en matière de coloration syntaxique sont une affaire de goûts personnels, mais on peut néanmoins énoncer quelques principes de bon sens, au regard de la hiérarchie des catégories syntaxiques du langage et des caractéristiques de l'œil humain (mais en gardant à l'esprit que ces règles sont subjectives, comme les précédentes).

• Pour diminuer la fatigue, on privilégie un arrière‑plan sombre (on parle de dark mode), noir ou du moins très foncé. En effet, plus l'arrière plan s'approche du gris moyen, plus il écrase le contraste avec le texte (surtout s'il est en couleur) ; à la longue, la lecture devient pénible.
• Pour tous les éléments structurels qui articulent le code, le style gras aide à renforcer la perception ; de plus, il est opportun de choisir des couleurs primaires, vives, qui attirent l'attention et qui contrastent bien entre elles ; par exemple, on peut choisir de mettre :
• les mots‑clefs en rouge,
• les séparateurs et délimiteurs en bleu.
• Pour les opérateurs qui sont, comme les délimiteurs et séparateurs, des symboles isolés, on peut choisir le même format bleu, éventuellement avec une nuance de couleur.
• Pour les descripteurs de types et leurs valeurs numériques associées, on peut choisir du vert (c'est la troisième couleur primaire).
• Enfin, pour les commentaires, on privilégie le style italique, plus semblable à l'écriture manuscrite (donc d'apparence moins formelle que le code proprement dit), et dans une nuance de gris qui apparaît moins vive que le code, mais qui contraste suffisamment avec l'arrière‑plan pour rester lisible.

En définitive, cette combinaison de couleurs et de styles permet de gagner en lisibilité, tant sur moniteur que sur feuille imprimée, même en noir et blanc (les éditeurs de code savent éliminer la couleur d'arrière‑plan lors d'une impression).