PEP-8-tutorial: codestandaarden in Python

PEP-8, of de Python Enhancement Proposal, presenteert enkele kernpunten die je kunt gebruiken om je code overzichtelijker en leesbaarder te maken. Zoals Python-bedenker Guido Van Rossum zegt:

Code wordt veel vaker gelezen dan geschreven.

In deze post ga je PEP-8 verkennen met enkele codevoorbeelden! Je behandelt de volgende onderwerpen:

• Eerst maak je kennis met PEP-8: wat het is en waarom je het nodig hebt;
• Vervolgens pak je inspringing aan, een hot topic onder programmeurs. Gebruik je tabs of spaties? Je ontdekt het antwoord in deze sectie;
• Misschien verwacht je het niet, maar er zijn richtlijnen voor de maximale regellengte;
• Ook is er een voorgestelde manier om met lege regels om te gaan;
• Verder zijn spaties in expressies en statements iets wat je als beginner ook makkelijk kunt aanpakken;
• Wat is encoding en waarom heb je het nodig wanneer je met Python werkt? Wat is de standaardencoding voor Python3? De sectie over bronbestandsencoding behandelt dit allemaal.
• Waarschijnlijk doe je vaak imports tijdens het coderen. Deze sectie behandelt onderwerpen zoals de volgorde van je imports, absolute en relatieve imports, wildcard-imports, enz.;
• Documentatie is essentieel om alle onderdelen van een applicatie bij te houden en verbetert de algehele kwaliteit van het eindproduct. Commentaar is hier onmisbaar!
• Ken je module-level dunder-namen? Deze zijn bijzonder handig in docstrings!
• Tot slot leer je meer over naamgevingsconventies: je ontdekt hoe je functienamen kunt bedenken, welk type naamgevingsstijl je typisch gebruikt, en nog veel meer;
• Is je code PEP-8-compliant? Is zeker een vraag die je jezelf zou moeten stellen. Daarom behandelt de laatste sectie enkele tools die je helpen te controleren of je code zich houdt aan de richtlijnen die in deze post en de vele andere die hier niet zijn behandeld, staan!

Een introductie tot PEP-8

De programmeertaal Python is uitgegroeid tot een van de voorkeurs­talen voor velen. Het is een taal die relatief eenvoudig te leren is, multi-paradigma is, veel open-sourcemodules heeft die de bruikbaarheid vergroten, en een go-to tool is in de data science- en webontwikkelingsgemeenschap.

Je kunt echter pas profiteren van de voordelen van Python wanneer je weet hoe je je ideeën beter in code kunt uitdrukken. Python is met bepaalde doelen in gedachten gemaakt; deze doelen zie je wanneer je import this typt.

import this

The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Het bovenstaande zijn de 20 principes die Python hanteert, bekend als de Zen of Python. Je ziet ook "Readability Counts" in de output hierboven, wat je voornaamste zorg zou moeten zijn tijdens het schrijven van code: andere programmeurs of data scientists moeten je code kunnen begrijpen en eraan kunnen bijdragen zodat de taak kan worden opgelost.

De volgende secties geven je meer inzicht in hoe je het bovenstaande kunt bereiken!

Inspringing

Bij het programmeren in Python gebruik je zeker inspringing. Wees er echter voorzichtig mee, want het kan tot syntaxfouten leiden. De aanbeveling is daarom om vier spaties te gebruiken voor inspringing. Deze instructie gebruikt bijvoorbeeld vier spaties inspringing:

if True:
    print("If works")

En ook deze for-lus met print-statement is ingesprongen met vier spaties:

for element in range(0, 5):
    print(element)

Wanneer je een grote expressie schrijft, is het het beste om de expressie verticaal uit te lijnen. Als je dit doet, creëer je een "hanging indent".

Hier zijn enkele voorbeelden van hanging indents in grote expressies, die variaties laten zien van hoe je dit kunt gebruiken:

1. value = square_of_numbers(num1, num2,
                          num3, num4)
   

2. def square_of_number(
        num1, num2, num3, 
        num4):
    return num1**2, num2**2, num3**2, num4**2
   

3. value = square_of_numbers(
                 num1, num2,
                 num3, num4)
   

4. list_of_people = [
    "Rama",
    "John",
    "Shiva"
   ]
   

5. dict_of_people_ages = {
    "ram": 25,
    "john": 29,
    "shiva": 26
   }
   

Elke developer die met Python of een andere programmeertaal werkt, vraagt zich op een bepaald moment af of hij tabs of spaties moet gebruiken voor inspringing. Het verschil tussen tabs en spaties is een doorlopende discussie in de community. Bekijk bijvoorbeeld dit Stackoverflow-artikel.

Over het algemeen hebben spaties de voorkeur voor inspringing, maar als je Python-scripts aantreft die al tabs gebruiken, kun je doorgaan met inspringen met tabs. Anders moet je de inspringing van alle expressies in je script wijzigen naar spaties.

Let op dat Python 3 het mixen van tabs en spaties voor inspringing niet toestaat. Kies daarom een van de twee en houd je eraan!

Maximale regellengte

Over het algemeen is het goed om te mikken op een regellengte van 79 tekens in je Python-code.

Het volgen van dit streefgetal heeft veel voordelen. Enkele daarvan zijn de volgende:

• Het is mogelijk om bestanden naast elkaar te openen om te vergelijken;
• Je kunt de hele expressie bekijken zonder horizontaal te scrollen, wat bijdraagt aan betere leesbaarheid en begrip van de code.

Commentaarregels zouden 72 tekens regellengte moeten hebben. Je leert later in deze tutorial meer over de meest gangbare conventies voor commentaar!

Uiteindelijk is het aan jou welke conventies en stijl je volgt als je in een kleine groep werkt, en is het voor de meeste developers acceptabel om af te wijken van de richtlijn voor maximale regellengte. Maar als je aan een open-sourceproject werkt of eraan bijdraagt, wil en/of moet je je waarschijnlijk houden aan de maximale regellengte die door PEP-8 is vastgelegd.

Bij gebruik van de +-operator kun je beter een nette regeleinde gebruiken, wat je code begrijpelijker maakt:

Als alternatief kun je ook schrijven:

total = A
        + B
        + C

Kortom, je kunt een regeleinde toevoegen vóór of na een binaire operator, zolang je maar consistent bent. Als je nieuwe code schrijft, probeer dan de laatst getoonde optie te volgen, waarbij je een regeleinde vóór de binaire operator toevoegt.

Lege regels

In Python-scripts worden functies en klassen op topniveau gescheiden door twee lege regels. Methode-definities binnen klassen moeten worden gescheiden door één lege regel. Je ziet dit duidelijk in het volgende voorbeeld:

import unittest

class SwapTestSuite(unittest.TestCase):
    """
        Swap Operation Test Case
    """
    def setUp(self):
        self.a = 1
        self.b = 2

    def test_swap_operations(self):
        instance = Swap(self.a,self.b)
        value1, value2 =instance.get_swap_values()
        self.assertEqual(self.a, value2)
        self.assertEqual(self.b, value1)


class OddOrEvenTestSuite(unittest.TestCase):
    """
        This is the Odd or Even Test case Suite
    """
    def setUp(self):
        self.value1 = 1
        self.value2 = 2

    def test_odd_even_operations(self):
        instance1 = OddOrEven(self.value1)
        instance2 = OddOrEven(self.value2)
        message1 = instance1.get_odd_or_even()
        message2 = instance2.get_odd_or_even()
        self.assertEqual(message1, 'Odd')
        self.assertEqual(message2, 'Even')

De klassen SwapTestSuite en OddOrEvenTestSuite worden gescheiden door twee lege regels, terwijl de methode-definities, zoals .setUp() en .test_swap_operations(), slechts één lege regel hebben om ze te scheiden. De code wordt succesvol uitgevoerd, maar zal geen output genereren omdat de code om de unittest te draaien ontbreekt (het toont alleen best practices).

Spaties in expressies en statements

Probeer spaties te vermijden wanneer je ziet dat je code eruitziet zoals in de volgende voorbeelden:

Deze voorbeelden zijn afkomstig uit PEP-8.

Bronbestandsencoding

Een computer kan geen "letters", "getallen", "afbeeldingen" of iets anders opslaan; hij kan alleen bits opslaan en ermee werken, die slechts binaire waarden kunnen hebben: yes of no, true of false, 1 of 0, enz. Zoals je al weet, werkt een computer met elektriciteit; dit betekent dat een "daadwerkelijke" bit de aanwezigheid of afwezigheid van een elektrische puls is. Je zou deze (afwezige) aanwezigheid doorgaans weergeven met 1 en 0.

Om bits te gebruiken om iets anders dan bits voor te stellen, heb je een set regels nodig. Je moet een reeks bits omzetten in iets als letters, cijfers en afbeeldingen met behulp van een encodingschema of encoding. Voorbeelden van encodingschema's zijn ASCII, UTF-8, enz.:

• De American Standard Code for Information Interchange (ASCII) is het meest voorkomende formaat voor tekstbestanden op computers en op internet. In dit type bestanden wordt elk alfabetisch, numeriek of speciaal teken weergegeven met een 7-bits binair getal (een reeks van zeven 0'en of 1'en).
• Unicode Worldwide Character Standard, of kortweg Unicode, is een systeem voor "the interchange, processing, and display of the written texts of the diverse languages of the modern world". Kortom, Unicode is ontworpen om alle bekende schriftsystemen ter wereld te ondersteunen. Unicode gebruikt momenteel drie verschillende encodings om Unicode-tekenreeksen te representeren: UTF-8, UTF-16 en UTF-32.
  • UTF-16 is een Unicode-encoding met variabele lengte: codepoints worden gecodeerd met één of twee 16-bits code-units.
  • UTF-8 is een ander type Unicode-encoding met variabele lengte, met één tot vier 8-bits bytes.
  • UTF-32 is een encoding met vaste lengte die precies 32 bits per Unicode-codepoint gebruikt.

Tip: als je meer wilt weten over encoding, bekijk dan deze post.

Waarom is dit belangrijk?

Je zult gemerkt hebben dat strings tot de meest gebruikte datatypes in Python behoren. Zoals je kunt verwachten, komt er een moment dat je wilt werken met strings die tekens bevatten of volledig bestaan uit tekens die niet deel uitmaken van de standaard ASCII-set. Het kan immers zijn dat je met teksten moet werken die accenten bevatten, zoals á, ž, ç enz.

In Python 3 is UTF-8 de standaard bronencoding. Maar voor wie Python 2 gebruikt: daar is de standaard ASCII.

Maar wat als je een string hebt die een niet-ASCII-teken bevat, zoals "Flügel"?

Wanneer je de string in Python 2 aanroept, krijg je het volgende:

>>> s 
'Fl\xfcgel'

Dit lijkt niet op je string! Wat gebeurt er wanneer je hem print?

>>> print(s)
Flügel

Printen gaf je de waarde die je aan de variabele hebt toegewezen. Het niet-ASCII-teken ÃŒ werd gecodeerd. Daarom kreeg je \xfc terug toen je de string aanriep. Om dit te verwerken, kun je gebruikmaken van de stringmethoden .encode() en .decode(). De eerste geeft een 8-bits stringversie van de Unicode-string terug, gecodeerd in de gevraagde encoding, terwijl de laatste de string interpreteert met de opgegeven encoding.

Imports

Het importeren van libraries en/of modules is iets wat je vaak doet wanneer je met Python voor data science werkt. Zoals je waarschijnlijk al weet, moet je libraries altijd aan het begin van je script importeren.

Let op dat als je veel imports doet, je ervoor moet zorgen dat je elke import op een aparte regel zet.

Bekijk de volgende tabel om dit beter te begrijpen:

Daarnaast moet je er rekening mee houden dat er een volgorde is die je moet respecteren wanneer je libraries importeert. In het algemeen kun je deze volgorde aanhouden:

1. Imports uit de standaardbibliotheek.
2. Gerelateerde third-party imports.
3. Lokale applicatie-/libraryspecifieke imports.

Absolute en relatieve imports

Verder is het goed om het verschil te kennen tussen absolute en relatieve imports. In het algemeen hebben absolute imports de voorkeur in Python, omdat ze de leesbaarheid vergroten. Maar naarmate je applicatie complexer wordt, kun je ook relatieve imports blijven gebruiken. Impliciete relatieve imports mogen nooit worden gebruikt en zijn in Python 3 verwijderd.

Maar wat zijn absolute en relatieve imports?

• Een absolute import is een import die het absolute pad van de functie of klasse gebruikt, gescheiden door .. Bijvoorbeeld,

    import sklearn.linear_model.LogisticRegression
  

• Een relatieve import is een import die relatief is ten opzichte van de huidige positie waar je Python-bestand zich bevindt. Je kunt dit type import gebruiken als je projectstructuur groeit, omdat het je project leesbaarder maakt. Dat betekent dat, als je een Python-projectstructuur hebt zoals de volgende:

    .
    ├── __init__.py
    ├── __init__.pyc
    ├── __pycache__
    │   ├── __init__.cpython-35.pyc
    │   ├── bubble_sort.cpython-35.pyc
    │   ├── selection_sort.cpython-35.pyc
    ├── bubble_sort.py
    ├── heap_sort.py
    ├── insertion_sort.py
    ├── insertion_sort.pyc
    ├── merge_sort.py
    ├── merge_sort.pyc
    ├── quick_sort.py
    ├── radix_sort.py
    ├── selection_sort.py
    ├── selection_sort.pyc
    ├── shell_sort.py
    ├── tests
    │   ├── test1.py
  

Je een relatieve import kunt gebruiken om het bubblesort-algoritme BubbleSort, opgeslagen in bubble_sort.py, in test1 te importeren. Dat ziet er zo uit:

from ..bubble_sort import BubbleSort

Als je meer wilt weten over absolute en relatieve imports, bekijk dan PEP 328.

Wildcard-imports

Tot slot moet je wildcard-imports proberen te vermijden, omdat ze niet bijdragen aan de leesbaarheid; je hebt geen zicht op welke classes, methods of variabelen je uit je module gebruikt, bijvoorbeeld:

from scikit import *

Commentaar

Commentaar wordt in Python gebruikt voor documentatie in de code. Het draagt bij aan het begrip van de code. Er zijn veel tools die je kunt gebruiken om documentatie te genereren, zoals comments en docstrings, voor je eigen module. Commentaar moet uitgebreider zijn, zodat iemand die de code leest een goed begrip krijgt van de code en hoe die samenwerkt met andere delen van de code.

Commentaar begint met het symbool #. Alles wat na de hekje staat, wordt niet uitgevoerd door de interpreter. In het volgende codeblok geeft de code bijvoorbeeld alleen "This is a Python comment" terug.

# This is a Python single line comment
print("This is a Python comment")

Onthoud: in de vorige sectie las je dat commentaarregels een regellengte van 72 tekens zouden moeten hebben!

Er zijn drie soorten commentaar:

• Je gebruikt blokcommentaar om code uit te leggen die complexer is of onbekend voor anderen. Dit zijn doorgaans langere commentaren en ze zijn van toepassing op een deel of alle code die volgt. Blokcommentaar is op hetzelfde niveau ingesprongen als de code. Elke regel van een blokcommentaar begint met het hekje # en één spatie. Als je meer dan één alinea nodig hebt, moeten deze worden gescheiden door een regel die alleen # bevat.

Bekijk het volgende fragment, genomen uit de scikit-learn-bibliotheek, om te begrijpen hoe dit commentaar eruitziet:

   if Gram is None or Gram is False:
        Gram = None
        if copy_X:
            # force copy. setting the array to be fortran-ordered
            # speeds up the calculation of the (partial) Gram matrix
            # and allows to easily swap columns
            X = X.copy('F')

• Inline commentaar moet je spaarzaam gebruiken, ook al kan het effectief zijn wanneer je bepaalde delen van je code moet uitleggen. Ze kunnen je ook helpen herinneren wat een specifieke coderegel betekent of handig zijn wanneer je samenwerkt met iemand die niet met alle aspecten van je code bekend is. Je gebruikt inline commentaar op dezelfde regel als een statement, volgend op de code zelf. Dit commentaar begint ook met # en één spatie.

Bijvoorbeeld:

counter = 0  # initialize the counter

• Je schrijft documentatiestrings of docstrings aan het begin van publieke modules, bestanden, klassen en methoden. Dit type commentaar begint met """ en eindigt met """:

    """
        This module is intended to provide functions for scientific computing 
    """

Module-level dunder-namen

Nu je hebt gelezen wat docstrings zijn, moet je ook weten dat module-level dunders, of namen met twee leidende en twee afsluitende underscores, zeer effectief zijn in Python. Dit zijn de speciale namen die Python definieert zodat ze niet in conflict komen met door de gebruiker gedefinieerde functies of namen. Voor meer informatie kun je dit artikel bekijken.

Een module-level dunder zoals (__all__, __author__, __version__) moet worden geplaatst bij de hoofd-docstring van de module en vóór alle import-statements. Je moet de imports from __future__ definiëren vóór alle andere code, behalve de docstrings:

"""
    Algos module consists of all the basic algorithms and their implementation
"""

from __future__ import print

__all__ = ['searching', 'sorting']
__version__ = '0.0.1'
__author__ = 'Chitrank Dixit'

import os
import sys

Tip: bekijk de volgende conventies voor het schrijven van docstrings.

Naamgevingsconventies

Wanneer je in Python programmeert, maak je vrijwel zeker gebruik van een naamgevingsconventie: een set regels voor het kiezen van de tekenreeks die gebruikt moet worden voor identifiers die variabelen, types, functies en andere entiteiten in broncode en documentatie aanduiden.

Als je niet zeker weet welke naamgevingsstijlen er zijn, overweeg dan de volgende:

• b of een enkele kleine letter;
• B of een enkele hoofdletter;
• lowercase
• UPPERCASE
• lower_case_with_underscores
• UPPER_CASE_WITH_UNDERSCORES
• CapitalizedWords, ook bekend als CapWords, CamelCase of StudlyCaps.
• mixedCase
• Capitalized_Words_With_Underscores
• _single_leading_underscore: zwakke indicator voor "intern gebruik". Bijvoorbeeld, from M import * importeert geen objecten waarvan de naam met een underscore begint.
• single_trailing_underscore_: gebruikt volgens conventie om conflicten met Python-trefwoorden te vermijden, bijvoorbeeld Tkinter.Toplevel(master, class_='ClassName')
• __double_leading_underscore: bij het benoemen van een klasseattribuut, activeert name mangling (binnen klasse FooBar wordt __boo _FooBar__boo).
• __double_leading_and_trailing_underscore__: "magische" objecten of attributen die leven in door de gebruiker beheerde namespaces. Bijvoorbeeld __init__, __import__ of __file__. Je zou dergelijke namen nooit zelf moeten verzinnen, maar alleen gebruiken zoals gedocumenteerd.

Algemene naamgevingsconventies

De volgende tabel laat enkele algemene richtlijnen zien over hoe je je identifiers benoemt:

• Gebruik geen 'l', 'O' of 'I' als enkele variabelenaam: deze tekens lijken in sommige lettertypes op nul (0) en (1).
• Over het algemeen is het goed om, waar mogelijk, korte namen te gebruiken. In sommige gevallen kun je underscores gebruiken om de leesbaarheid te verbeteren.

Als je meer wilt weten over de uitzonderingen op de algemene naamgevingsconventies, bekijk dan dit artikel.

Is je code PEP-8-compliant?

Na meer te hebben geleerd over PEP-8 vraag je je waarschijnlijk af hoe je kunt controleren of je code daadwerkelijk aan deze richtlijnen voldoet (en meer die in deze tutorial niet aan bod zijn gekomen!).

Naast zelf PEP-8 te bekijken en er meer over te leren, is het een goed idee om de handige pep8-module, het coala-pakket en enkele andere alternatieven die in de volgende secties worden beschreven, te bekijken!

Python pep8-pakket

Het pep8-pakket kan worden gebruikt om PEP-8-incompatibiliteit in je Python-code te controleren en wijzigingen voor te stellen om de PEP-8-richtlijnen te volgen. Je kunt de pep8-module installeren met pip door het volgende commando uit te voeren:

pip install pep8

Om te demonstreren hoe pep8 werkt, maak je een nieuw Python-bestand met de naam example.py met de volgende code:

def my_function(a, b):
    print("The sum of a and b is: ", a + b)

a = 1
b = 2

my_function(a,b)

Sla het bestand op en voer vervolgens het commando pep8 erop uit in je terminal of opdrachtprompt als volgt:

pep8 example.py

Dit zal alle PEP-8-incompatibiliteiten weergeven die pep8 in de code heeft gedetecteerd, zoals:

example.py:1:1: E302 expected 2 blank lines, found 0
example.py:3:5: E225 missing whitespace around operator
example.py:5:5: E225 missing whitespace around operator

De eerste regel van de output geeft aan dat er twee lege regels vóór de functiedefinitie op regel 1 zouden moeten staan. De volgende twee regels geven aan dat er witruimte rond de optelling-operator in het print-statement en de toewijzingsstatements moet staan.

Om deze problemen op te lossen, kun je de code als volgt aanpassen:

def my_function(a, b):
    print("The sum of a and b is:", a + b)

a = 1
b = 2

my_function(a, b)

Als je nu pep8 example.py opnieuw uitvoert, zou er geen output moeten zijn, wat aangeeft dat de code nu PEP-8-compliant is.

Je kunt ook de broncode bekijken waar de incompatibiliteit is gevonden met het argument --show-source:

$ pep8 --show-source --show-pep8 testsuite/E40.py
testsuite/E40.py:2:10: E401 multiple imports on one line
import os, sys
         ^
    Imports should usually be on separate lines.

    Okay: import os\nimport sys
    E401: import sys, os

Of je kunt laten zien hoe vaak elke fout is gevonden door --statistics toe te voegen:

$ pep8 --statistics -qq Python-2.5/Lib
232     E201 whitespace after '['
599     E202 whitespace before ')'
631     E203 whitespace before ','
842     E211 whitespace before '('
2531    E221 multiple spaces before operator
4473    E301 expected 1 blank line, found 0
4006    E302 expected 2 blank lines, found 1
165     E303 too many blank lines (4)
325     E401 multiple imports on one line
3615    E501 line too long (82 characters)
612     W601 .has_key() is deprecated, use 'in'
1188    W602 deprecated form of raising exception

Tip: bekijk ook zeker andere modules, zoals flake8, autopep8 of pylint!

Je code analyseren met coala

coala biedt linting en fixes voor alle talen, maar je bent hier meer gericht op Python. Je kunt coala installeren met pip:

$ pip3 install coala-bears

In het codeblok hierboven zie je dat je eigenlijk coala-bears installeert: bears zijn plugins of eenvoudige modules die de mogelijkheden van je coala uitbreiden en per taal verschillen. In dit geval wil je pep8bear gebruiken, die PEP-8-incompatibele code vindt en die ter plekke fixt. Je zou dit zeker moeten overwegen om je Python-code te controleren.

$ coala -S python.bears=PEP8Bear python.files=\*\*/\*.py \
python.default_actions=PEP8Bear:ApplyPatchAction --save
# other output ...
Executing section python...
[INFO][11:03:37] Applied 'ApplyPatchAction' for 'PEP8Bear'.
[INFO][11:03:37] Applied 'ApplyPatchAction' for 'PEP8Bear'.

pep8online: Check je Python-code online

Bovenop de handige pep8-module en het coala-pakket kun je ook controleren of je Python-code PEP-8-compliant is door naar pep8online te gaan. Deze site heeft een online editor waarin je je code kunt plakken en op de knop "Check code" kunt drukken! Als resultaat krijg je feedback over wat je moet verbeteren. Lekker handig!

Conclusie

Bij het gebruik van Python let je soms minder op codekwaliteit door de drang om sneller features uit te brengen. Toch zouden de praktijken die in deze tutorial zijn beschreven - en de vele meer die hier niet zijn behandeld - deel moeten uitmaken van je develop-staging-test-deploy-cyclus. Dit is voor iedereen die aan het project werkt gunstig om te begrijpen en vaak kunnen wijzigingen in de code worden gedaan zonder diep te graven en de code te hoeven begrijpen door meteen debuggers te starten. Als je aan een open-sourceproject werkt, zullen je bijdragers PEP-8 waarderen en je code beter begrijpen, omdat dit de universele standaard is; elke Python-developer volgt deze.

Nu je deze tutorial hebt doorlopen, is het een heel goed idee om zelf de PEP-8 te bekijken! Er valt nog veel meer te ontdekken.

Als je nog tips hebt over hoe je aan PEP-8 kunt voldoen of als je vindt dat we iets belangrijks in dit artikel hebben gemist, laat het ons dan weten via @DataCamp.