Pour s'assurer de la qualité du code, Ruff est également utilisé.
Tout comme pour le format, Ruff doit tourner avant chaque commit.
!!!note "to edit or not to edit"
Vous constaterez sans doute que `ruff format` modifie votre code,
mais que `ruff check` vous signale juste une liste
d'erreurs sans rien modifier.
En effet, `ruff format` ne s'occupe que de la forme du code,
alors que `ruff check` regarde la logique du code.
Si Ruff modifiait automatiquement la logique du code,
ça serait un coup à introduire plus de bugs que ça n'en résoud.
Il existe cependant certaines catégories d'erreurs que Ruff
peut réparer de manière sûre.
Pour appliquer ces réparations, faites :
```bash
ruff check --fix
```
## Documentation
La documentation est écrite en markdown, avec les fonctionnalités
offertes par MkDocs, MkDocs-material et leurs extensions.
La documentation est intégralement en français, à l'exception
des exemples, qui suivent les conventions données plus haut.
### Découpage
La séparation entre les différentes parties de la documentation se fait
en suivant la méthodologie [Diataxis](https://diataxis.fr/).
On compte quatre sections :
1. Explications : parlez dans cette section de ce qui est bon à savoir
sans que ça touche aux détails précis de l'implémentation.
Si vous parlez de *pourquoi* un choix a été fait ou que vous montrez
grossièrement les contours d'une partie du projet, c'est une explication.
2. Tutoriels : parlez dans cette section d'étapes précises
ou de détails d'implémentation qu'un nouveau développeur
doit suivre pour commencer à travailler sur le projet.
3. Utilisation : parlez dans cette section de méthodes utiles
pour un développeur qui a déjà pris en main le projet.
Voyez cette partie comme un livre de recettes de cuisine.
4. Référence : parlez dans cette section des détails d'implémentation du projet.
En réalité, vous n'aurez pas besoin de beaucoup vous pencher dessus,
puisque cette partie est composée presque uniquement
des docstrings présents dans le code.
Pour plus de détails, lisez directement la documentation de Diataxis,
qui expose ces concepts de manière beaucoup plus complète.
### Style
Votre markdown doit être composé de lignes courtes ;
à partir de 88 caractères, c'est trop long.
Si une phrase est trop longue pour tenir sur une ligne,
vous pouvez l'écrire sur plusieurs.
Une ligne ne peut pas contenir plus d'une seule phrase.
Dit autrement, quand vous finissez une phrase,
faites systématiquement un saut de ligne.
=== "Bien ✔️"
```markdown linenums="1"
First shalt thou take out the Holy Pin,
then shalt thou count to three, no more, no less.
Three shalt be the number thou shalt count,
and the number of the counting shalt be three.
Four shalt thou not count, neither count thou two,
excepting that thou then proceed to three.
Five is right out.
Once the number three, being the third number, be reached,
then lobbest thou thy Holy Hand Grenade of Antioch towards thou foe,
who being naughty in My sight, shall snuff it.
```
=== "Pas bien ❌"
```markdown linenums="1"
First shalt thou take out the Holy Pin, then shalt thou count to three, no more, no less. Three shalt be the number thou shalt count, and the number of the counting shalt be three. Four shalt thou not count, neither count thou two, excepting that thou then proceed to three. Five is right out. Once the number three, being the third number, be reached, then lobbest thou thy Holy Hand Grenade of Antioch towards thou foe, who being naughty in My sight, shall snuff it.
```
À noter que ces deux exemples donnent le même résultat
dans la documentation générée.
Mais la version avec de courtes lignes est beaucoup
plus facile à modifier et à versioner.
!!!warning "Grammaire et orthographe"
Ca peut paraitre évident dit comme ça, mais c'est toujours bon à rappeler :
