← Terug naar Kennisbank← Vorige vraagVolgende vraag →
ProgrammatiePython Team Lead

Vertel over naamgevingsconventies (PEP8 enz.) in Python. Hoe beïnvloedt het niet naleven van deze conventies de praktijk van het werken met code? Geef voorbeelden van de werkelijke gevolgen van het schenden van PEP8 in projecten.

Slaag voor sollicitatiegesprekken met de Hintsage AI-assistent

Antwoord.

In Python zijn er verschillende code-stijlconventies, waarvan de belangrijkste PEP8 is:

  • Naam van variabelen/functies: lower_case_with_underscores
  • Naam van klassen: CapitalizedCamelCase
  • Constanten: ALL_CAPS
  • Regellengte: tot 79 tekens
  • Inspringingen: 4 spaties (geen tabs!)
  • Spaties rond operatoren: a = b + c
  • Imports: elke import op een aparte regel, eerst standaard bibliotheken, dan externe, dan lokale

Het naleven van PEP8 vergemakkelijkt teamwork, verhoogt de leesbaarheid, verlaagt de instapdrempel, vereenvoudigt de automatisering van tests, enz.

Vragend met een valstrik.

In PEP8 wordt aanbevolen om geen éénletterige namen voor variabelen te gebruiken. Maar mag je korte namen gebruiken in list comprehensions of in lambda? Waarom?

Antwoord: In de basis worden éénletterige namen toegestaan voor korte iteraties (bijvoorbeeld in list comprehensions voor markeringsvariabelen zoals x, i, j) om korte expressies niet te overbelasten. Voor complexe uitdrukkingen is het beter om betekenisvolle namen te geven.

Voorbeeld:

# Toegestaan:
squares = [x**2 for x in numbers]
# Beter:
squares = [number**2 for number in numbers]

Voorbeelden van werkelijke fouten door onwetendheid over de nuances van het onderwerp.

Verhaal 1

In een bankproject kwamen we erachter dat een deel van de functies en parameters in verschillende tradities was genoemd (CamelCase, snake_case, met een streepje). Een nieuw teamlid raakte voortdurend in de war over waar de namen precies werden gebruikt - bijna twee weken gingen verloren met het oplossen van conflicten en het hernoemen van variabelen.

Verhaal 2

In een data-engineeringproject werden inspringingen niet nageleefd, en werden tabs en spaties door elkaar gehaald. Dit leidde tot SyntaxError op verschillende ontwikkelstations, en sommige ontwikkelaars besteedden uren aan het zoeken naar overbodige spaties.

Verhaal 3

Op een groot educatief platform werden korte en lange variabele namen door elkaar gebruikt. Bijvoorbeeld, een functie voor logverwerking werd l() genoemd, terwijl de inlogverwerker long heette, wat in veel IDE's veel tijd kostte voor navigatie en verwarring veroorzaakte bij het gebruiken van de functie met het element l uit de lijst.