# Voici ces **10 règles**, avec explication simplifiée :

## ✅ 1. **Limiter le code à une seule action par ligne**

* **Pourquoi** : Cela améliore la lisibilité et réduit les erreurs de compréhension.
* **Exemple** :
  ❌ `if (x = 0) y = 3;`
  ✅

  ```c
  if (x == 0)
      y = 3;
  ```

---

## ✅ 2. **Déclarer les variables dès leur utilisation**

* **Pourquoi** : Évite les erreurs dues à l’utilisation accidentelle d’anciennes valeurs ou de variables mal initialisées.

---

## ✅ 3. **Limiter la portée des variables**

* **Pourquoi** : Moins une variable est accessible, plus on maîtrise son usage et donc ses effets secondaires.

---

## ✅ 4. **Éviter l’utilisation de l’allocation dynamique**

* **Pourquoi** : La mémoire dynamique (`malloc`, `new`) est difficile à maîtriser dans des systèmes critiques (fuites mémoire, fragmentation).

---

## ✅ 5. **Limiter la complexité cyclomatique**

* **Pourquoi** : Mesurer le nombre de chemins logiques dans une fonction. S'il y en a trop, le code devient difficile à tester/examiner.
* **Règle** : ≤ 10 branches de décision par fonction.

---

## ✅ 6. **Limiter la profondeur d’imbrication à 3 niveaux**

* **Pourquoi** : Améliore la lisibilité et diminue la complexité mentale.

---

## ✅ 7. **Limiter chaque fonction à 60 lignes maximum**

* **Pourquoi** : Une fonction courte est plus facile à lire, tester, maintenir.

---

### ✅ 8. **Utiliser uniquement un sous-ensemble sûr du langage C**

* **Pourquoi** : Certains aspects du C sont dangereux (pointeurs, arithmétique non définie…).
* **Exemple** : Éviter les arithmétiques sur des pointeurs, `goto`, les unions, etc.

---

## ✅ 9. **Inclure des commentaires structurés**

* **Pourquoi** : Le code critique doit être **documenté de manière formelle** (description, entrées/sorties, exceptions, etc.).

---

## ✅ 10. **Compiler avec tous les warnings activés et traiter chaque warning comme une erreur**

* **Pourquoi** : Cela pousse à écrire du code propre dès la compilation.

---

## 📌 Bonus : autres pratiques de la NASA/JPL

* **Tests unitaires automatisés systématiques**
* **Revue de code systématique en binôme**
* **Pas de raccourcis ni d’optimisation prématurée**
* **Pas de dépendance non maîtrisée**
* **Analyse statique obligatoire**

---

### 📘 Source principale :

* Gerard J. Holzmann – *"The Power of Ten – Rules for Developing Safety Critical Code"*, NASA/JPL.

Souhaites-tu que je t’en fasse un **poster** ou un **document PDF** à imprimer pour ton équipe ?