Polar Code 🎭

Command Palette

Search for a command to run...

13
Pièce N°13

Le Code du Survécu – Bonnes Pratiques

Dans l’ombre, la précision est une question de vie ou de mort. Un espace mal placé, une variable nommée temp, un silence après une erreur… Ce sont ces petites choses qui transforment un plan brillant en un désastre. Écrire un script Bash, c’est plus que faire fonctionner le code. C’est écrire un testament qui devra être relu, compris, et peut-être exécuté dans la panique, par vous ou par un autre. Voici les règles pour survivre.

1. Commenter le code

Les commentaires ne sont pas pour la machine. Ils sont pour le fantôme que vous serez à 4h du matin dans six mois, essayant de comprendre pourquoi vous avez écrit ça. Ou pour votre complice.

  • Mauvais :
    ls -la | grep .log | awk '{print $9}'
    
  • Bon :
    # Lister uniquement les noms des fichiers .log dans le répertoire courant
    # 1. Lister tous les fichiers avec leurs détails
    # 2. Filtrer pour ne garder que les lignes contenant '.log'
    # 3. Extraire seulement le nom du fichier (9ème champ)
    ls -la | grep .log | awk '{print $9}'
    
    Expliquez le POURQUOI, pas le comment (sauf si le comment est obscur). En-tête de script obligatoire :
    #!/bin/bash
    # Nom : nettoyeur_ombres.sh
    # Auteur : Nuit
    # Description : Supprime les fichiers temporaires et nettoie les logs des 7 derniers jours.
    # Usage : ./nettoyeur_ombres.sh [--force]
    # Dépendances : coreutils, find
    

2. Nommer clairement variables et scripts

Un nom est une promesse. x ou data ne promettent rien. compte_tentatives_ssh ou chemin_dossier_backup racontent une histoire.

  • Mauvais :
    f="/home/u/log.txt"
    n=$(wc -l $f)
    
  • Bon :
    chemin_fichier_log="/home/user/application.log"
    nombre_lignes_erreur=$(grep -c "ERROR" "$chemin_fichier_log")
    
    Pour les scripts : backup.sh est vague. backup_mysql_incremental.sh est clair.

3. Vérifier les erreurs

Ne jamais faire confiance. Vérifier le code de retour, l’existence des fichiers, les permissions. set -euo pipefail est votre base, mais parfois il faut plus de finesse.

  • Négligence suicidaire :
    cp "$fichier_sensible" "/media/usb/"
    rm "$fichier_sensible"  # Et si la copie a échoué ?
    
  • Paranoïa salvatrice :
    if ! cp "$fichier_sensible" "/media/usb/"; then
        echo "[ERREUR] Échec de la copie. Le fichier source n'a pas été supprimé." >&2
        exit 1
    fi
    rm "$fichier_sensible"
    echo "[SUCCÈS] Transfert et suppression terminés."
    

4. Éviter le code dupliqué

Si vous copiez-collez un bloc de code, c’est un signe. Créez une fonction. C’est plus propre, plus facile à maintenir, et si vous trouvez un bug, vous ne le corrigez qu’à un seul endroit.

  • Avant (duplication) :
    echo "Début traitement des logs système..."
    find /var/log -name "*.log" -mtime +30 -exec rm {} \;
    echo "Fin traitement des logs système."
    
    echo "Début traitement des logs applicatifs..."
    find /opt/app/logs -name "*.log" -mtime +30 -exec rm {} \;
    echo "Fin traitement des logs applicatifs."
    
  • Après (avec fonction) :
    supprimer_vieux_logs() {
        local dossier="$1"
        echo "Début traitement des logs dans $dossier..."
        find "$dossier" -name "*.log" -mtime +30 -exec rm {} \;
        echo "Fin traitement."
    }
    
    supprimer_vieux_logs "/var/log"
    supprimer_vieux_logs "/opt/app/logs"
    

5. Scripts portables

Votre script ne vivra pas toujours sur votre machine. Utilisez #!/usr/bin/env bash plutôt que #!/bin/bash pour trouver Bash où qu’il soit. Méfiez-vous des chemins absolus, des outils non standards.

  • Fragile :
    #!/bin/bash
    # Suppose que 'grep' a toujours l'option -P (Perl regex), ce qui n'est pas vrai partout.
    grep -P '\d{3}-\d{3}' fichier.txt
    
  • Robuste :
    #!/usr/bin/env bash
    # Utilise une regex POSIX étendue (-E), plus portable.
    grep -E '[0-9]{3}-[0-9]{3}' fichier.txt
    
    Vérifiez les dépendances au début du script :
    # Vérification des commandes nécessaires
    for cmd in awk date find; do
        if ! command -v "$cmd" &>/dev/null; then
            echo "[ERREUR] Commande '$cmd' manquante. Abandon." >&2
            exit 127
        fi
    done
    

Le bon script n’est pas celui qui fonctionne une fois sur votre machine. C’est celui qui fonctionne toujours, partout, qui est lisible par un inconnu sous pression, et qui échoue de façon bruyante et claire quand le monde ne répond pas à ses attentes.

C’est la différence entre un bidouilleur et un professionnel de l’ombre. Le professionnel survit. Le professionnel laisse un héritage utilisable, pas un champ de ruines.

Écrivez pour survivre.