← Retour à la Base de connaissances← Question précédenteQuestion suivante →
ProgrammationResponsable de l'équipe Python

Parlez-nous des conventions de nommage (PEP8, etc.) en Python. Comment le non-respect de ces conventions affecte-t-il la pratique de travail avec le code ? Donnez des exemples réels des conséquences de la violation de PEP8 dans les projets.

Réussissez les entretiens avec l'assistant IA Hintsage

Réponse.

En Python, il existe plusieurs conventions de style de code, dont la principale est PEP8:

  • Nom des variables/fonctions: lower_case_with_underscores
  • Nom des classes: CapitalizedCamelCase
  • Constantes: ALL_CAPS
  • Longueur de ligne: jusqu'à 79 caractères
  • Indentation: 4 espaces (pas de tabulations!)
  • Espaces autour des opérateurs: a = b + c
  • Imports: chaque import sur une ligne séparée, d'abord les librairies standards, ensuite les tierces, puis locales.

Le respect de PEP8 facilite le travail d'équipe, améliore la lisibilité, réduit la barrière d'entrée, simplifie l'automatisation des tests, etc.

Question piège.

PEP8 recommande de ne pas utiliser des noms de variables d'une seule lettre. Cependant, peut-on utiliser des noms courts dans les list comprehensions ou dans les lambda ? Pourquoi ?

Réponse : Dans le cas de courtes itérations (par exemple, dans les list comprehensions pour des variables-marquages, comme x, i, j), il est permis d'utiliser des noms d'une seule lettre afin de ne pas surcharger les expressions courtes. Pour des expressions plus complexes, il est préférable de donner des noms significatifs.

Exemple :

# Acceptable :
squares = [x**2 for x in numbers]
# Mieux :
squares = [number**2 for number in numbers]

Exemples d'erreurs réelles dues à la méconnaissance des subtilités du sujet.

Histoire 1

Dans un projet bancaire, nous avons rencontré le problème où certaines fonctions et paramètres étaient nommés selon des traditions différentes (CamelCase, snake_case, avec des tirets). Un nouveau membre de l'équipe se trompait constamment sur les noms utilisés — presque deux semaines ont été nécessaires pour résoudre les conflits et renommer les variables.

Histoire 2

Dans un projet d'ingénierie des données, l'indentation n'était pas respectée, il y avait un mélange de tabulations et d'espaces. Cela a conduit à des SyntaxError sur différentes stations de développement, et certains développeurs passaient des heures à rechercher des espaces superflus.

Histoire 3

Sur un grand portail éducatif, des noms de variables courts et longs étaient mélangés. Par exemple, la fonction pour traiter les logs était nommée l(), tandis que le gestionnaire de connexion était long, ce qui a pris beaucoup de temps pour naviguer dans de nombreux IDE et a causé de la confusion lors de l'utilisation de la fonction avec l'élément l d'une liste.