The Invent with Python Blog

The Zen of Python door Tim Peters zijn 20 richtlijnen voor het ontwerp van de Python taal. Je Python code hoeft niet per se deze richtlijnen te volgen, maar ze zijn goed om in gedachten te houden. De Zen van Python is een paasei, of verborgen grap, die verschijnt als je import this:

>>> import thisThe Zen of Python, by Tim PetersBeautiful 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!

opmerking: op mysterieuze wijze zijn slechts 19 van de richtlijnen opgeschreven. Guido van Rosum zei naar verluidt dat het ontbrekende 20e aforisme “een bizarre Tim Peters in-grap is.”

uiteindelijk zijn deze richtsnoeren adviezen die voor of tegen kunnen worden verdedigd. Zoals alle goede morele codes spreken ze zichzelf soms tegen om de meeste flexibiliteit te bieden. Hier is mijn eigen interpretatie van deze aforismen:

mooi is beter dan lelijk.

programmeurs schrijven vaak snel code zonder zich zorgen te maken over de leesbaarheid. Hoewel code niet leesbaar hoeft te zijn, moet de code van de Python-taal zelf doordacht zijn, consistent, en een plezier om te gebruiken. Natuurlijk hoeft niet elk script mooi te zijn, en schoonheid is subjectief, maar veel van Python ‘ s populariteit is een gevolg van het feit dat zo gemakkelijk om mee te werken.

expliciet is beter dan impliciet.

“dit aforisme spreekt voor zich,” dat zou een verschrikkelijke verklaring zijn voor elk aforisme. Op dezelfde manier is het beter voor code om uitgebreid en expliciet te zijn. Je moet voorkomen dat het verbergen van de functionaliteit van de code achter obscure taal functies die vertrouwdheid vereisen om volledig te begrijpen.

eenvoudig is beter dan complex. Complex is beter dan ingewikkeld.

deze twee aforismen herinneren ons eraan dat het bouwen van alles kan worden gedaan met behulp van eenvoudige of complexe technieken. Met een eenvoudig probleem, zoals het bouwen van een vogelhuisje, is een eenvoudige oplossing beter. Het bouwen van een dieseltreinmotor is daarentegen een complex probleem dat complexe technieken vereist. Zelfs als je technisch een dieseltreinmotor zou kunnen maken met behulp van birdhouse technieken, zou je waarschijnlijk eindigen met een ingewikkelde, Rube Goldberg opstelling van birdhouse onderdelen die geen ideale oplossing zou zijn. Geef de voorkeur aan eenvoud boven complexiteit, maar ken de grenzen van eenvoud.

vlak is beter dan genest.

programmeurs organiseren dingen graag in categorieën, vooral categorieën die subcategorieën bevatten die andere sub-subcategorieën bevatten. Deze hiërarchieën voegen vaak niet zozeer organisatie toe als wel bureaucratie. Het is goed om code te hebben in slechts één toplaag module of klasse in plaats van op te splitsen over meerdere submodules of subklassen. Als je pakketten en modules maakt die code vereisen zoals import spam.eggs.bacon.ham.foo.bar, dan maak je je code te ingewikkeld.

schaars is beter dan dicht.

programmeurs proppen vaak zoveel mogelijk functionaliteit in zo weinig mogelijk code, zoals one-liners zoals de volgende: print('\n'.join("%i bytes = %i bits which has %i possible values." % (j, j*8, 256**j-1) for j in (1 . While code like this may impress their friends, it'll infuriate their coworkers who have to try to understand it. Code that is spread out over multiple lines is often easier to read than dense one-liners.

leesbaarheid telt.

terwijl strcmp() duidelijk de “string compare” – functie kan betekenen met iemand die sinds de jaren zeventig programmeert in C, hebben moderne computers voldoende geheugen om de volledige functienaam uit te schrijven. Laat geen klinkers vallen van uw namen of schrijf te kort code. Code wordt vaker gelezen dan geschreven, dus expliciete, leesbare code is belangrijker dan korte, ongedocumenteerde code.

speciale gevallen zijn niet speciaal genoeg om de regels te overtreden. Hoewel praktisch beter is dan zuiver.

deze twee aforismen, die als een verzameling komen, spreken elkaar tegen. Programmeren zit vol “best practices” waar programmeurs naar moeten streven in hun code. Plinten deze praktijken voor een snelle hack kan verleidelijk zijn, maar kan leiden tot een rattennest van inconsistente, onleesbare code. Echter, bukken om zich te houden aan regels kan resulteren in zeer abstracte, onleesbare code. De poging van de programmeertaal Java om alle code aan te passen aan zijn objectgeoriënteerde paradigma resulteert vaak in veel boilerplate code voor zelfs het kleinste programma. Het lopen van de lijn tussen deze twee aforismen wordt gemakkelijker met ervaring. En mettertijd zul je niet alleen de regels leren, maar ook leren wanneer je ze moet breken.

fouten mogen nooit stilletjes voorbij gaan. Tenzij uitdrukkelijk het zwijgen is opgelegd.

omdat programmeurs vaak foutmeldingen negeren, betekent niet dat het programma moet stoppen met het uitzenden ervan. Stille fouten kunnen optreden wanneer functies foutcodes of None retourneren in plaats van uitzonderingen. Deze twee aforismen vertellen ons dat het beter is voor een programma om fail fast en crash dan om de fout stil te leggen en door te gaan met het uitvoeren van het programma. De bugs die onvermijdelijk later gebeuren zal moeilijker te debuggen zijn omdat ze ver verwijderd zijn van de oorspronkelijke oorzaak. Hoewel je er altijd voor kunt kiezen om expliciet de fouten te negeren die je programma ‘ s veroorzaken, zorg er gewoon voor dat je de bewuste keuze maakt om dit te doen.

in het licht van dubbelzinnigheid, weiger de verleiding om te raden.Computers hebben mensen bijgelovig gemaakt: om de demonen in onze computers uit te drijven voeren we het heilige ritueel uit om ze uit te schakelen en vervolgens aan te zetten. Vermoedelijk zal dit elk mysterieus probleem oplossen. Computers zijn echter geen magie. Als uw code niet werkt, is er een reden en alleen voorzichtig, kritisch denken zal het oplossen. Weiger de verleiding om blindelings oplossingen te proberen totdat iets lijkt te werken; vaak heb je het probleem alleen maar gemaskeerd in plaats van opgelost.

er moet één—en bij voorkeur maar één-voor de hand liggende manier zijn om dit te doen.

dit is een breed front tegen het motto van de Perl programmeertaal, ” er is meer dan één manier om het te doen!”Het blijkt dat het hebben van drie of vier verschillende manieren om code te schrijven die hetzelfde doet een tweesnijdend zwaard is: je hebt flexibiliteit in hoe je code schrijft, maar nu moet je elke mogelijke manier leren om het te kunnen lezen. Deze flexibiliteit is de 3x of 4x inspanning die nodig is om een programmeertaal te leren niet waard.

hoewel die manier in het begin misschien niet duidelijk is, tenzij je Nederlander bent.

deze regel is een grap. Guido Van Rossum, de bedenker en Bdfl (welwillende Dictator voor het leven) van Python, is Nederlands. Echter, zelfs dit aforisme verhinderde Python van het opnemen van drie verschillende manieren van het formatteren van strings.

nu is beter dan nooit. Hoewel nooit is vaak beter dan * rechts * nu.

deze twee aforismen vertellen ons dat code die in oneindige lussen hangt of gevangen wordt duidelijk erger is dan code die dat niet doet. echter, het is vrijwel zeker beter om te wachten tot je programma klaar is dan om het te vroeg af te maken met onjuiste resultaten.

als de implementatie moeilijk uit te leggen is, is het een slecht idee. Als de implementatie gemakkelijk uit te leggen is, kan het een goed idee zijn.

Python streeft ernaar de taak van de programmeur gemakkelijker te maken in plaats van de computer aan te passen zodat een programma sneller loopt. En programma ‘ s moeten begrijpelijk zijn, niet alleen door de programmeur die het schreef, maar ook door andere programmeurs die de code onderhouden. Deze twee aforismen herinneren ons eraan dat als “high-performance” code zo ingewikkeld is dat het onmogelijk is voor programmeurs om te begrijpen en te debuggen, het dan slechte code is. Maar helaas, alleen omdat het makkelijk is om de code van een programma aan iemand anders uit te leggen, betekent niet dat het geen slechte code is. Programmeren is moeilijk.

Namespaces zijn een geweldig idee-Laten we er meer van doen!

naamruimten (en ook globale en lokale scopes) zijn de sleutel om te voorkomen dat namen in een module of scope botsen met namen in een andere module. Maar vergeet ook niet dat flat beter is dan geneste: hoe groot ze ook zijn, namespaces moeten alleen worden gemaakt om naamgevingsconflicten te voorkomen, en niet om onnodige categorisatie toe te voegen.

zoals alle meningen over programmeren, kunnen de meningen die ik hier heb geschreven worden tegengesproken of kunnen ze gewoon irrelevant zijn voor uw situatie. Ruziën over hoe code moet worden geschreven is zelden zo productief als je denkt dat het is. (Tenzij je een heel boek schrijft vol programmeer meningen.)