Spécification d'abord, implémentation après (top-down)

C'est l'approche recommandée quand vous devez écrire un programme depuis zéro. L'idée de cette approche est de décomposer le problème en sous-problèmes puis d'écrire les spécifications des fonctions qui vont permettre de résoudre ces sous-problèmes, avant de les implémenter.

Pour ce faire, vous pouvez utiliser du pseudo-code pour vous donner une idée de l'algorithme que vous allez implémenter ainsi que des sous-problèmes que vous allez devoir résoudre. Ensuite, vous allez pouvoir spécifier les fonctions qui vont résoudre ces sous-problèmes en écrivant leurs préconditions et postconditions. Enfin, il sera possible d'implémenter ces fonctions en convertissant le pseudo-code en code C.

Implémentation d'abord, refactoring après (bottom-up)

C'est une approche qui est parfois utile quand vous voulez créer un prototype rapide et que vous n'avez pas beaucoup de temps ou d'expérience avec le problème à résoudre. L'idée de cette approche est d'implémenter rapidement un programme fonctionnel mais qui n'est pas forcément très bien structuré pour ensuite faire du refactoring, c'est-à-dire réorganiser le code pour le rendre plus lisible et mieux structuré notamment en créant des fonctions pour extraire les fragments de code qui se répètent. C'est une approche qui est plus risquée car si l'étape de refactoring n'est jamais faite, le code peut devenir très difficile à lire et à maintenir.

Une seule responsabilité par fonction

Le principe de responsabilité unique est une bonne pratique qui nous dit qu'une fonction doit avoir une seule responsabilité. Cela signifie qu'une fonction doit faire une seule chose et la faire bien plutôt que de faire plusieurs choses à la fois, ce qui peut rendre le code plus difficile à lire et à maintenir. Une bonne règle de base est que si vous avez du mal à décrire ce que fait une fonction en une seule phrase, c'est probablement qu'elle fait trop de choses. Dans ce cas, il est souvent possible de diviser la fonction en plusieurs fonctions plus petites. Il est important de noter que faire "une seule chose" peut avoir plusieurs significations en fonction du niveau d'abstraction que l'on prend. Par exemple, si on prend le cas d'un jeu d'échecs, on pourrait avoir les fonctions suivantes :

• Abstraction basse : une fonction pour déplacer une pièce, une fonction pour capturer une pièce, une fonction pour vérifier si un roi est en échec, etc.
• Abstraction moyenne : une fonction pour jouer un tour, une fonction pour vérifier si le jeu est terminé, etc.
• Abstraction haute : une fonction pour jouer une partie, une fonction pour gérer le score, etc.

Identifiants et paramètres explicites

Comme pour les variables, il est important de choisir des noms de fonctions et de paramètres qui sont explicites et qui donnent une idée claire de ce que font les fonctions. En particulier, quand votre fonction utilise des valeurs qui ont des unités physiques comme des mètres, des secondes, des kilogrammes, etc., il peut être utile d'inclure ces unités dans le nom de la fonction ou des paramètres. Par exemple, si vous avez une fonction qui calcule une vitesse moyenne en mètres par seconde sur base d'une distance en mètres et d'une durée en secondes, vous pourriez l'appeler vitesse_moyenne_mps et avoir des paramètres distance_m et temps_s.

De plus, il est préférable de bien choisir l'ordre des paramètres, notamment en mettant les paramètres d'entrée avant les paramètres de sortie.

Refactoring

Même en essayant de spécifier tout à l'avance et de suivre l'approche top-down, il n'est souvent pas possible de tout prévoir et donc il est possible que vous vous retrouviez avec du code qui se répète ou des fonctions qui font trop de choses. Dans ce cas, il est important de faire du refactoring pour améliorer la structure du code.

Gardes

Dans certains cas, notamment quand vous avez besoin de gérer des erreurs, il est possible d'utiliser le fait que l'instruction return termine immédiatement l'exécution d'une fonction pour créer des gardes qui permettent de sortir rapidement d'une fonction si une condition n'est pas remplie. Cela permet de réduire le niveau d'indentation de certains fragments de code et de rendre le code plus lisible. Voici un petit exemple pour illustrer cela :

// PRE: /
// POST: divise a par b et renvoie le résultat si b n'est pas nul, affiche un message d'erreur et renvoie 0 sinon.
int safe_divide(int a, int b) {
    int result;
    if (b != 0) {
        result = a / b;
    } else {
        printf("Erreur : division par zéro\n");
        result = 0;
    }
    return result;
}

// PRE: /
// POST: divise a par b et renvoie le résultat si b n'est pas nul, affiche un message d'erreur et renvoie 0 sinon.
int safe_divide(int a, int b) {
    if (b == 0) {
        printf("Erreur : division par zéro\n");
        return 0;
    }

    return a / b;
}

Pas de variables globales

Il est possible de déclarer des variables globales qui sont accessibles depuis n'importe quelle fonction du programme, par exemple :

#include <stdio.h>

int compteur = 0;  // Variable globale

void incrementer(void) {
    compteur += 1;
}

int main(void) {
    incrementer();

    printf("Compteur : %d\n", compteur);  // Affiche "Compteur : 1"

    return 0;
}

Cependant, il est fortement déconseillé d'utiliser ces variables globales car elles rendent le code plus difficile à comprendre et à maintenir. Il est donc préférable d'utiliser des paramètres et des valeurs de retour pour partager des valeurs entre les fonctions, par exemple :

#include <stdio.h>

void incrementer(int *compteur) {
    *compteur += 1;
}

int main(void) {
    int compteur = 0;  // Variable locale

    incrementer(&compteur);

    printf("Compteur : %d\n", compteur);  // Affiche "Compteur : 1"

    return 0;
}

Ces variables globales ont aussi le problème d'avoir une portée sur le programme entier. Il est donc possible de déclarer une variable locale dans une fonction sans remarquer qu'elle a le même nom qu'une variable globale. Cela ne pose pas de problème car la variable globale sera juste masquée mais c'est déconseillé car cela peut prêter à confusion, par exemple :

#include <stdio.h>

int compteur = 0;  // Variable globale

int main(void) {
    int compteur = 1;  // Variable locale (qui masque la variable globale)

    printf("Compteur : %d\n", compteur);  // Affiche "Compteur : 1"

    return 0;
}

Division en modules et bibliothèques

En plus de diviser le code en fonctions, on peut aussi le diviser en modules et bibliothèques afin de mieux organiser le code.

#include "utils.h"

#include <stdbool.h>

bool est_premier(int nb) {
    int i = 2;

    while (nb > 1 && nb % i != 0) {
        i++;
    }

    return nb == i;
}

int somme_chiffres(int nb) {
    int somme = 0;

    while (nb > 0) {
        somme += nb % 10;
        nb = nb / 10;
    }

    return somme;
}

main.c
utils.c
utils.h

gcc -c utils.c -o utils.o  # Compile le module "utils" en un fichier objet "utils.o"
gcc main.c utils.o -o main  # Compile et lie le programme principal "main.c" avec le fichier objet "utils.o" pour créer l'exécutable "main"

gcc -c utils.c -o utils.o  # Compile le module "utils" en un fichier objet "utils.o"
gcc -c main.c -o main.o  # Compile le programme principal "main.c" en un fichier objet "main.o"
gcc main.o utils.o -o main  # Lie le fichier objet "main.o" avec le fichier objet "utils.o" pour créer l'exécutable "main"

gcc main.c utils.c -o main  # Compile le programme principal "main.c" et le module "utils" puis lie les deux pour créer l'exécutable "main"

arithmetic.c
arithmetic.h
geometry.c
geometry.h

gcc -c arithmetic.c -o arithmetic.o  # Compile le module "arithmetic" en un fichier objet "arithmetic.o"
gcc -c geometry.c -o geometry.o  # Compile le module "geometry" en un fichier objet "geometry.o"
gcc -shared arithmetic.o geometry.o -o libbetter_math.so  # Crée la bibliothèque "libbetter_math.so" à partir des fichiers objets