Skip to content

Commit

Permalink
Update 2025-01-22-black-lint.md
Browse files Browse the repository at this point in the history
  • Loading branch information
Cindyvlv authored and lepiaf committed Nov 27, 2024
1 parent 7de3829 commit 2bc123a
Showing 1 changed file with 15 additions and 13 deletions.
28 changes: 15 additions & 13 deletions _articles/fr/2025-01-22-black-lint.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,9 +2,9 @@
contentType: article
lang: fr
date: 2025-01-22
slug: formatter-le-code-python-avec-black
title: Formatter le code Python avec Black
excerpt: "Le formattage du code est une source de querelle entre les membres d'une équipe. Résolvons le une bonne fois pour toute avec un formatteur de code : Black"
slug: formater-le-code-python-avec-black
title: Formater le code Python avec Black
excerpt: Le formatage du code est une source de querelle entre les membres d'une équipe. Résolvons le une bonne fois pour toute avec le formateur de code Black.
categories:
- architecture
keywords:
Expand All @@ -13,20 +13,20 @@ keywords:
authors:
- tthuon
cover:
alt: Astronautes qui nettoient un mur de données
alt: Comment formater son code Python avec l'outil Black ?
path: /imgs/articles/2025-01-22-black-lint/cover.jpg
seo:
title: Formatter le code Python avec Black
description: "Le formattage du code est une source de querelle entre les membres d'une équipe. Résolvons le une bonne fois pour toute avec un formatteur de code : Black"
title: Black : le formateur rapide de code python
description: Reformater tout votre code python, son style et sa vérification, automatiquement avec Black. Gain de temps garanti !
---

Le formattage du code est souvent une source de querelle entre les membres d'une équipe. Il existe pourtant une référence _Python Enhancement Proposals_ qui donne un guide sur le style à adopter : [PEP 8 - Style Guide for Python Code](https://peps.python.org/pep-0008/). Ce guide ne couvre pas tous les cas d'usage. Un même code peut être formatté de deux façon différente et être conforme à la spécification.
Le formatage du code est souvent une source de querelle entre les membres d'une équipe. Il existe pourtant une référence _Python Enhancement Proposals_ qui donne un guide sur le style à adopter : [PEP 8 - Style Guide for Python Code](https://peps.python.org/pep-0008/). Ce guide ne couvre pas tous les cas d'usage. Un même code peut être formaté de deux façons différentes et être conforme à la spécification.

Un outil avec des règles plus stricte existe : [Black](https://black.readthedocs.io/en/stable/index.html)

## Black - Le formateur de code sans compromis

Cet va appliquer des règles strictes dans le but d'avoir un code cohérent, généraliste, lisibe et avec des différences git réduite.
Cet outil va appliquer des règles strictes dans le but d'avoir un code cohérent, généraliste, lisible et avec des différences git réduites.

Les règles sont disponibles sur cette page : https://black.readthedocs.io/en/stable/the_black_code_style/current_style.html.

Expand Down Expand Up @@ -62,9 +62,9 @@ All done! ✨ 🍰 ✨

Maintenant que Black est installé et utilisé par tous les membres de l'équipe, automatisation et faisons respecter cet outils avec Gitlab CI.

## Intégration avec Gitlab CI
## Intégration de Black avec Gitlab CI

Généralement, dans votre fichier `.gitlab-ci.yml` vous avez déjà des tâches pour tester votre code. Ajoutons une étape de plus pour vérifier le formattage du code.
Généralement, dans votre fichier `.gitlab-ci.yml` vous avez déjà des tâches pour tester votre code. Ajoutons une étape de plus pour vérifier le formatage du code.

A la différence de l'exécution en local, nous voulons uniquement faire une vérification et montrer la différence. Cela permet à la personne de corriger plus facilement.

Expand All @@ -85,7 +85,7 @@ lint:
<div class="admonition note" markdown="1"><p class="admonition-title">Uniquement dans le cadre d'une merge request</p>
Ici, cette tâche s'exécute uniquement dans le cadre d'une merge request. Nous voulons nous assurer que le code qui sera fusionné dans la branche principale soit bien formatté. Il n'est pas nécessaire de l'exécuter de nouveau dans la branche principale.
Ici, cette tâche s'exécute uniquement dans le cadre d'une merge request. Nous voulons nous assurer que le code qui sera fusionné dans la branche principale soit bien formaté. Il n'est pas nécessaire de l'exécuter de nouveau dans la branche principale.
</div>
Voici la sortie en exemple
Expand Down Expand Up @@ -117,9 +117,11 @@ Oh no! 💥 💔 💥
1 file would be reformatted, 87 files would be left unchanged.
```

La personne devra corriger et Gitlab va de nouveau vérifier les changement.
La personne devra corriger et Gitlab va de nouveau vérifier les changements.

Fini les débats sans fin sur le formattage du code. Black défini une bonne fois pour toutes les règles à adopter par l'équipe. Ce projet est stable et est utilisé par de nombreux projet libre de droits tel que SQLAlachemy ou Django.
## Conclusion

Fini les débats sans fin sur le formatage du code. Black défini une bonne fois pour toutes les règles à adopter par l'équipe. Ce projet est stable et utilisé par de nombreux projets libres de droits tel que SQLAlachemy ou Django.

## Références

Expand Down

0 comments on commit 2bc123a

Please sign in to comment.