Bonnes pratiques de script et analyse statique
Découvrez les conventions de codage, les commentaires et l’utilisation d’outils comme ShellCheck pour écrire des scripts Bash propres, lisibles et sans erreur.
Bonnes pratiques de script et analyse statique est une leçon Linux Command Line & Bash Scripting Mastery gratuite sur CoddyKit. Ceci est la leçon 3 sur 4. Tu peux lire la leçon complète ci-dessous gratuitement — puis la pratiquer en direct dans le navigateur avec un éditeur de code intégré et un tuteur IA 24/7. Elle fait partie du parcours d'apprentissage Linux Command Line & Bash Scripting Mastery, et ta progression se synchronise sur le web et l'application CoddyKit. Le cours Linux Command Line & Bash Scripting Mastery comprend 4 leçons au total.
Pourquoi suivre les bonnes pratiques de script ?
Écrire des scripts Bash est puissant, mais sans de bonnes habitudes, les scripts peuvent devenir difficiles à comprendre, à maintenir et à déboguer.
Les bonnes pratiques sont des recommandations qui vous aident à écrire un code propre, robuste et lisible. Elles rendent vos scripts :
- Plus faciles à lire : pour vous-même et pour les autres.
- Plus faciles à maintenir : plus simples à mettre à jour ou à corriger.
- Moins sujets aux erreurs : en évitant les erreurs courantes.
- Plus adaptés au travail en équipe : en uniformisant l’apparence et le comportement du code.
Des commentaires pour plus de clarté
Les commentaires sont essentiels pour expliquer pourquoi votre code fait quelque chose, et pas seulement ce qu’il fait. Ils servent de notes pour vous-même à l’avenir ou pour les autres développeurs.
Utilisez des commentaires pour :
- décrire l’objectif général du script au début ;
- expliquer une logique complexe ou des sections délicates ;
- documenter les fonctions : leur objectif, leurs arguments et leurs valeurs de retour.
Commencez un commentaire par le symbole # (dièse).
#!/bin/bash
# This script demonstrates commenting best practices.
# Author: CoddyKit
# Date: 2023-10-27
# Function: greet_user
# Description: Prints a greeting message to the console.
# Arguments:
# $1 - The name of the user to greet.
greet_user() {
local name="$1" # Store the first argument in a local variable.
echo "Hello, ${name}!" # Output the greeting message.
}
# Main script execution starts here.
echo "Script execution started."
greet_user "CoddyKit Learner" # Call the function with a specific name.
echo "Script execution finished."Des conventions de nommage claires
Des noms explicites rendent votre script plus facile à suivre. Évitez les variables à une seule lettre, sauf lorsqu’il s’agit de compteurs de boucle courants (comme i ou j).
Conventions générales :
- Variables : utilisez des noms descriptifs (par exemple,
user_nameoulog_file). UtilisezUPPERCASEpour les variables d’environnement ou les constantes globales. Utilisezlowercase_with_underscorespour les variables locales du script. - Fonctions : utilisez
lowercase_with_underscores, en commençant souvent par un verbe (par exemple,process_dataoucheck_status). - Scripts : utilisez
lowercase_with_hyphens(par exemple,backup-script.sh).
Mise en forme et indentation cohérentes
Une mise en forme cohérente, notamment pour l’indentation et les espaces, améliore considérablement la lisibilité. Imaginez que vous lisiez un livre dont les paragraphes seraient indentés de manière incohérente !
Points essentiels :
- Utilisez 2 ou 4 espaces pour l’indentation (les tabulations sont souvent déconseillées).
- Gardez des lignes courtes (moins de 80 caractères est une bonne règle générale pour les terminaux).
- Utilisez des lignes vides pour séparer les blocs de code logiques.
- Alignez les éléments associés lorsque cela est pertinent.
La cohérence est plus importante que le style précis que vous choisissez.
Robustesse : 'set -u' (nounset)
L’option set -u (ou set -o nounset) est très utile pour éviter les bogues causés par des fautes de frappe ou par des variables accidentellement non définies. Si votre script essaie d’utiliser une variable à laquelle aucune valeur n’a été attribuée, set -u quitte immédiatement le script avec une erreur.
Cela permet de détecter les erreurs rapidement et d’éviter les comportements inattendus plus loin dans votre script.
Essayez d’exécuter le code ci-dessous. Il est conçu pour s’arrêter rapidement, car UNSET_NAME n’est pas définie.
#!/bin/bash
# Demonstrating 'set -u' (nounset)
set -u # Exit if an unset variable is used
MY_GREETING="Hello"
echo "${MY_GREETING}, CoddyKit!"
# This variable is NOT set. With 'set -u', the script will exit here.
echo "Your name is: ${UNSET_NAME}"
echo "This line will NOT be reached if 'set -u' is active and UNSET_NAME is indeed unset."Robustesse : 'set -o pipefail'
Lorsque vous reliez des commandes par un pipeline (par exemple, cmd1 | cmd2 | cmd3), Bash ne signale normalement que le statut de sortie de la dernière commande du pipeline. Ainsi, si cmd1 échoue mais que cmd2 et cmd3 réussissent, le pipeline peut tout de même signaler une réussite !
set -o pipefail modifie ce comportement. Si une quelconque commande du pipeline échoue (renvoie un statut de sortie différent de zéro), le statut de sortie de l’ensemble du pipeline sera cette valeur différente de zéro.
Vos pipelines deviennent ainsi plus fiables, car l’échec d’une commande précoce est signalé immédiatement.
#!/bin/bash
# Demonstrating 'set -o pipefail'
set -o pipefail # Ensures pipe's exit status is the last non-zero command
echo "Running a failing command in a pipe:"
echo "---"
# 'false' command always fails (exit status 1).
# 'cat /dev/null' always succeeds (exit status 0).
# With 'set -o pipefail', the pipe's overall exit status will be 1 from 'false'.
false | cat /dev/null
# This line will only be reached if the pipe above succeeds.
echo "---"
echo "Script finished successfully (this line won't show if pipe failed with set -o pipefail)."Découvrir ShellCheck
Même en suivant les bonnes pratiques, il est facile de laisser passer de petites erreurs de syntaxe ou des pièges courants. C’est là que ShellCheck intervient !
ShellCheck est un outil d’analyse statique (un outil de vérification) pour les scripts shell. Il lit votre script et signale :
- les erreurs de syntaxe ;
- les erreurs courantes des débutants ;
- les problèmes sémantiques subtils ;
- les problèmes de portabilité entre différents shells.
Il fournit des suggestions utiles, souvent accompagnées de liens vers des explications plus détaillées.
ShellCheck en action : un script incorrect
Examinons un script qui présente quelques problèmes courants. Ils peuvent ne pas provoquer immédiatement un plantage du script, mais il s’agit de mauvaises pratiques ou de bogues potentiels.
Imaginez que vous avez enregistré ce script sous le nom bad_script.sh. Pour exécuter ShellCheck sur celui-ci, vous devez saisir : shellcheck bad_script.sh
Voyez si vous pouvez repérer les problèmes avant d’exécuter ShellCheck !
#!/bin/bash
# A script with some common issues
MY_NAME=coddykit # Variable assignment needs no space, but quoting is good for values
echo "Hello $MY_NAME!" # Missing quotes around variable expansion
if [ $1 = "admin" ]; then # Missing quotes around $1
echo "Welcome, administrator."
fi
# A simple loop with potential issues
for file in *.txt; do # Unquoted glob could expand to multiple arguments
echo File: $file # Missing quotes around $file
doneCorrection des avertissements de ShellCheck
ShellCheck fournirait une sortie comme celle-ci : SC2086: Double quotes missing around "$MY_NAME". Il indique souvent un code précis (comme SC2086) que vous pouvez rechercher pour obtenir plus de détails.
Voici le script précédent, corrigé conformément aux recommandations de ShellCheck et aux bonnes pratiques générales :
Remarquez l'utilisation de guillemets doubles "" autour des expansions de variables et des substitutions de commandes afin d'empêcher la séparation des mots et l'expansion des motifs, qui sont des sources fréquentes de bogues.
#!/bin/bash
# A script with issues fixed by ShellCheck
MY_NAME="CoddyKit" # Quote variable assignment values
echo "Hello ${MY_NAME}!" # Always quote variable expansions
if [ "$1" = "admin" ]; then # Quote positional parameters like $1
echo "Welcome, administrator."
fi
# A simple loop with corrected quoting
for file in *.txt; do
echo "File: ${file}" # Quote variable expansions, especially in loops
doneVérification des bonnes pratiques
Lesquelles des pratiques suivantes sont considérées comme de bonnes pratiques lors de l'écriture de scripts Bash ?
Récapitulatif : écrire des scripts professionnels
Félicitations ! Vous avez appris à faire passer vos scripts Bash du stade de scripts fonctionnels à celui de scripts professionnels.
Nous avons vu :
- L'importance des bonnes pratiques pour la lisibilité et la facilité de maintenance.
- L'utilisation de commentaires et de conventions de nommage pour améliorer la clarté.
- La manière de rendre les scripts robustes avec
set -uetset -o pipefail. - L'efficacité de ShellCheck pour trouver automatiquement les problèmes et améliorer votre code.
En appliquant ces principes, vous écrirez des scripts Bash plus fiables, plus compréhensibles et plus faciles à utiliser en équipe. Continuez à vous entraîner !
Questions Fréquemment Posées
La leçon « Bonnes pratiques de script et analyse statique » est-elle gratuite ?
Oui — le texte complet de « Bonnes pratiques de script et analyse statique » est gratuit à lire ici sur le web. Pour la pratiquer de manière interactive (un éditeur de code intégré et un tuteur IA 24/7) et déverrouiller le reste du cours Linux Command Line & Bash Scripting Mastery, passe à CoddyKit PRO. Le cours Linux Command Line & Bash Scripting Mastery comprend 4 leçons au total.
Qu'est-ce que j'apprendrai dans « Bonnes pratiques de script et analyse statique » ?
Découvrez les conventions de codage, les commentaires et l’utilisation d’outils comme ShellCheck pour écrire des scripts Bash propres, lisibles et sans erreur. Tu pratiques Linux Command Line & Bash Scripting Mastery avec du code pratique que tu exécutes directement dans le navigateur, et un tuteur IA 24/7 répond à tes questions au fur et à mesure que tu avances dans la leçon.
Dois-je avoir de l'expérience pour commencer Linux Command Line & Bash Scripting Mastery ?
Aucune expérience préalable n'est requise. Linux Command Line & Bash Scripting Mastery sur CoddyKit est structuré pour les débutants jusqu'aux apprenants avancés, donc tu peux commencer ici ou depuis le début et avancer à ton rythme. Ceci est la leçon 3 sur 4.
Combien de temps prend la leçon « Bonnes pratiques de script et analyse statique » ?
La plupart des leçons CoddyKit prennent environ 5–10 minutes. Chacune est courte et interactive, tu progresses régulièrement et tu repiques exactement où tu t'es arrêté sur le web et l'app.
Peux-tu écrire et exécuter du code dans cette leçon Linux Command Line & Bash Scripting Mastery ?
Oui. Chaque leçon Linux Command Line & Bash Scripting Mastery inclut un éditeur de code intégré, tu écris et exécutes du vrai code directement dans ton navigateur et tu reçois des retours IA instantanés — aucune configuration locale requise.
Toutes les leçons de ce cours
- Débogage des scripts Bash (set -x, trap)
- Gestion des erreurs et statut de sortie
- Bonnes pratiques de script et analyse statique
- Tester des scripts Bash avec Bats