Wat is de Zen van Python en hoe inspireert die een mogelijke Zen C?

Wanneer we het hebben over ontwerpfilosofie in talen van programmeringHet is gebruikelijk dat het volgende zich voordoet. De welbekende Zen van Python: die verzameling aforismen die verschijnt tijdens het schrijven import this in de console. Het is echter gemakkelijk om dit idee te verwarren met dat van een zogenaamde "Zen C-programmeertaal" of met de zoektocht naar een equivalent van "Zen" binnen de C-taal zelf. In de praktijk hebben we te maken met een reeks principes die gemeenschappen zoals die van Python hebben geïnspireerd en die veel ontwikkelaars proberen te extrapoleren naar andere talen zoals C, in plaats van een nieuwe taal genaamd Zen C.

In dit artikel gebruiken we die basis om in detail uit te leggen wat de Zen van Python is en hoe het werkt. Welke filosofie brengt het over, en in hoeverre kan het een hypothetische Zen van C inspireren?We zullen de aforismen één voor één onderzoeken, praktische voorbeelden, nuances en werkelijke tegenstrijdigheden in de ontwikkeling van de taal bespreken, en afsluiten met een reflectie op hoe deze principes buiten het Python-ecosysteem kunnen worden toegepast.

Wat Zen werkelijk is (en waarom dat belangrijk is als we het over Zen C hebben)

De zogenaamde Zen van Python, ook wel bekend als PEP20Het is een verzameling aforismen die Tim Peters' visie op het ontwerpen en schrijven van Python-code samenvatten. Hoewel veel mensen het aanhalen alsof het een soort grondwet is, begon het oorspronkelijk als een relatief luchtige tekst, met een flinke dosis ironie en een vleugje humor.

Deze aforismen worden beschouwd als een soort manifest van goede praktijkenDit zijn geen formele regels van de taal, maar ze hebben de cultuur van de gemeenschap, het schrijven van PEP's (Python Enhancement Proposals) en debatten over de evolutie van de taal zelf sterk beïnvloed: van de introductie van de "walrus"-operator (:=) totdat de structurele patronen overeenkomen.

Wanneer mensen het over "Zen C" hebben, vragen velen zich eigenlijk af of er een equivalent van deze principes voor C bestaat, of dat deze aangepast kunnen worden. filosofie van eenvoud, helderheid en leesbaarheid in de context van de C-taal, die een lager niveau heeft en minder "gebruiksvriendelijk" is ontworpen dan Python.

In de praktijk, wanneer iemand het over Zen C heeft, bedoelt men meestal hetzelfde idee: een handvol richtlijnen om duidelijkere en beter onderhoudbare C-code te schrijven, geïnspireerd door de principes van Zen of Python. Er bestaat geen officiële PEP 20 voor C, noch een magische module zoals deze. import this.

Hoe Python's Zen eruitziet in de console

Een van de bekendste eigenaardigheden van Python is dat je Zen in elke interactieve interpreter kunt weergeven door simpelweg te typen. import thisSinds Python 2.2.1 heeft de interpreter de module opgenomen. this.py die, wanneer geïmporteerd, de aforismen in het Engels afdrukt.

De tekst die verschijnt, bestaat uit een reeks van 19 korte zinnen die de ontwerpfilosofie van Python samenvatten. Er wordt gezegd dat Peters over 20 principes sprak, maar Hij liet slechts 19 geschriften na.waardoor het twintigste aforisme een soort "spookachtig" aforisme blijft dat iedereen zelf kan interpreteren of invullen.

Internally is de module this Het slaat Zen niet op in platte tekst, maar in een gecodeerde tekenreeks met een ROT13 Simpel. De module zelf definieert een tekenvervangingswoordenboek en decodeert de tekenreeks voordat deze wordt afgedrukt. Als je het inspecteert... this.sJe ziet de versleutelde versie; als je het substitutiealgoritme toepast, krijg je de leesbare tekst.

Dit gebruik van ROT13 verwijst naar het verleden: voordat de module bestond, werd Zen, eveneens versleuteld, gedeeld op de Python-mailinglijst als een soort Paasei voor de gemeenschapHet idee van "importeer dit" werd zelfs een slogan voor vroege ecosysteemconferenties, zoals de 10e Internationale Python-conferentie.

De 19 Zen-aforismen en hun praktische betekenis

De originele tekst, in het Engels, begint met de titel "The Zen of Python, by Tim Peters" en presenteert vervolgens 19 zinnen die elke Python-gebruiker wel eens heeft gelezen. We zullen ze hier één voor één bespreken en toelichten. wat ze impliceren in de dagelijkse programmeerpraktijk, hoe ze gewoonlijk worden geïnterpreteerd en enkele typische voorbeelden in Python die ons helpen ons voor te stellen hoe ze vertaald zouden kunnen worden naar een "Zen C".

1. Mooi is beter dan lelijk

De eerste regel benadrukt dat de code niet alleen moet functioneren, maar ook moet zijn prettig om te lezenSchoonheid draait hier niet om franje, maar om helderheid, consistentie en een zorgvuldige stijl: begrijpelijke namen, goed geplaatste ruimtes en een strakke structuur.

Een klassiek voorbeeld in Python is het prefereren van mensvriendelijke operatoren en trefwoorden zoals and y or geconfronteerd Symbolen Gebruik een cryptische formulering waar mogelijk, of vermijd dat verschillende bewerkingen op dezelfde regel worden gestapeld door leesbaarheid op te offeren voor beknoptheid.

Hetzelfde idee, toegepast op een hypothetische Zen C, zou suggereren om gebruik te maken van duidelijke inspringingsconventies, beschrijvende namen en complexe uitdrukkingen opsplitsen in meerdere regels, in plaats van macro's of ingewikkelde uitdrukkingen te misbruiken die alleen de schrijver ervan begrijpt.

2. Expliciet is beter dan impliciet.

Dit principe benadrukt dat de lezer van de code niet hoeft te raden hoe iets werkt. Het is beter dat de bedoeling duidelijk is. overdag geschreven, hoewel het misschien een paar extra regels code vereist, in plaats van te vertrouwen op impliciet gedrag of verborgen "magie".

Een veelvoorkomend voorbeeld is het vermijden van dingen zoals from math import *die alle inhoud van een module in de huidige namespace plaatsen zonder duidelijk te maken wat er precies gebruikt wordt. Het is beter om te schrijven: from math import sqrt, sin, cos en om expliciet aan te geven wat er nodig is.

Een andere manier om de code expliciet te maken is door te introduceren tussenliggende variabelen met expressieve namen In plaats van alle bewerkingen in één enkele expressie te proppen. Dat helpt iedereen (inclusief je toekomstige zelf) te begrijpen wat er gebeurt, zonder dat je in gedachten hoeft te reconstrueren wat er gebeurt.

3. Eenvoud is beter dan complexiteit

Het idee hierachter is dat, wanneer je de mogelijkheid hebt, Kies de eenvoudige oplossing boven de ingewikkelde.Het gaat er niet om koste wat kost alle complexiteit te vermijden, maar om te onthouden dat code één keer wordt geschreven en vele malen wordt gelezen.

Ervaren programmeurs benadrukken vaak dat het bereiken van eenvoud inspanning vergt: je moet het ontwerp verfijnen, functies extraheren, namen controleren... maar in ruil daarvoor krijg je... Schone en efficiënte code Het is gemakkelijk te begrijpen en kan zonder problemen worden onderhouden. Deze aanpak werkt zowel voor Python als voor C: een korte, duidelijke functie heeft de voorkeur boven een megafunctie vol speciale gevallen en statusvlaggen.

De voorbeelden contrasteren vaak implementaties waarbij alles in één cryptische regel wordt opgelost met iets langere versies, maar met duidelijke en goed gedefinieerde logische blokkendie veel gemakkelijker uit te leggen zijn.

4. Complex is beter dan ingewikkeld.

Het onderscheid tussen 'complex' en 'ingewikkeld' is belangrijk. Een complex systeem is opgebouwd uit... eenvoudige modules die combinerenMaar elk onderdeel is op zichzelf begrijpelijk. Een complex systeem daarentegen zit vol verborgen afhankelijkheden, gedeelde toestanden en logica die niet direct duidelijk is.

In code vertaalt dit zich naar een voorkeur voor ontwerpen waarbij elke functie een duidelijke taak uitvoert en afhankelijk is van andere, goed gedefinieerde functies, in plaats van alle logica op één plek te proppen met globale constanten, impliciete toestanden en moeilijk te volgen kruisvoorwaarden.

Geordende voorkeuren worden doorgaans als volgt samengevat: Eenvoudig > Complex > IngewikkeldMet andere woorden: als volledige eenvoud niet mogelijk is, laat de complexiteit dan in ieder geval gestructureerd zijn en geen onleesbare chaos.

5. Plat is beter dan in elkaar genesteld

Diep geneste structuren belemmeren snel begrip. Verschillende niveaus van ifLussen binnen lussen en geneste structuren dwingen de lezer om Je hoofd overbelasten met te veel informatie Tegelijkertijd. De Zen-aanbeveling is om af te vlakken wanneer dat redelijk is.

Een veelgebruikte techniek om eindeloze nesten te vermijden is Extraheer delen van de code in kleine hulpfuncties.of gebruik maken van meer directe controlemechanismen (zoals elif in plaats van else: if ... genest). Je kunt ook generatoren of pure functies gebruiken waarmee je collecties kunt verwerken zonder lussen binnen lussen.

In Python zou dit bijvoorbeeld betekenen dat drie geneste for-lussen worden omgezet in een reeks aaneengeschakelde generatorfuncties; in C, segmenteer zeer diepgaande functies in meerdere, vlakkere functies Het vermindert de visuele en logische complexiteit van elk onderdeel.

6. Verspreid is beter dan dicht.

Extreem compacte code lijkt op het eerste gezicht elegant, maar is vaak een pijn voor degene die hem moet onderhoudenZen moedigt aan om ademruimte te creëren: logische blokken in verschillende regels op te delen en waar nodig spaties en regelafbrekingen in te voegen.

Een zeer illustratief voorbeeld is Voeg voorwaardelijke statements, return-statements en functieaanroepen samen op één regel.Het is mogelijk, maar de kosten qua begrip zijn hoog. Door die logica op te splitsen in meerdere regels met tussenliggende namen wordt de stroom glashelder.

In Python worden leesbare list comprehensions en korte expressies aanbevolen; in C geldt hetzelfde voor het gebruik van operatoren, macro's en gekoppelde aanroepen, wat aan te raden is. implementeren in tussenstappen wanneer ze raadselachtig beginnen te worden.

7. Leesbaarheid is belangrijk.

De uitdrukking "Leesbaarheid is belangrijk" is bijna een Python-slogan geworden. De boodschap is duidelijk: De code wordt oneindig veel vaker gelezen dan geschreven.Het moet dus geoptimaliseerd worden voor de persoon die het gaat lezen, niet voor de persoon die het voor het eerst typt.

De syntaxis van Python zelf is ontworpen met die prioriteit in gedachten: Verplichte inspringing, duidelijke trefwoorden en weinig alternatieve manieren om hetzelfde te bereiken.In andere talen, zoals C, hangt de leesbaarheid veel meer af van de stijl van het team: het gebruik van naamgevingsconventies, zinvolle commentaren, goed gedefinieerde modules, enzovoort.

In beide gevallen dragen technieken zoals het toepassen van SOLID-principes, het putten van inspiratie uit "Clean Code"-ideeën of het consequent gebruiken van namen die de intentie verduidelijken, bij aan een duurzamere programmering op de lange termijn. nieuwe ontwikkelaars kunnen zonder problemen deelnemen.

8. Bijzondere gevallen zijn niet zo bijzonder dat ze de regels overtreden.

Dit aforisme gaat in op de terugkerende verleiding om te zeggen: "Dit geval is anders; we maken hier een uitzondering." Bij het definiëren van een reeks stijl- of ontwerpregels, als Elke eigenaardigheid wordt gebruikt als excuus om ze over te slaan.Uiteindelijk zijn de regels nutteloos.

Zen suggereert dat het zelfs in "bijzondere" gevallen beter is om te streven naar consistentie behoudenDit betekent dat het ontwerp moet worden aangepast aan de specifieke situatie, in plaats van stiekem een ​​kortere weg te kiezen die de algehele duidelijkheid van het systeem in gevaar brengt.

Dit principe is met name relevant bij het ontwerpen van API's, dataformaten of stijlgidsen in een groot team, waar elke uitzondering een uitdaging vormt. extra cognitieve belasting voor iedereen.

9. Hoewel praktische overwegingen het uiteindelijk van zuiverheid winnen.

Deze twee aforismen (regels en praktische overwegingen) houden elkaar in evenwicht. Enerzijds wordt consistentie geëist; anderzijds wordt erkend dat in de praktijk de realiteit vaak anders ligt. We kunnen niet altijd volledig 'puur' zijn. Bij het ontwerpen zijn soms pragmatische kortere routes nodig om deadlines te halen, rekening te houden met omgevingsbeperkingen of de acceptatie van een oplossing te vergemakkelijken.

Het belangrijkste is om niet te overdrijven: praktische overwegingen kunnen een goede basis vormen. Praktische snelkoppelingen om deadlines te halenMaar dat mag geen excuus zijn om slordig werk te accepteren. Een typisch voorbeeld in Python is het gebruik van beknopte constructies wanneer die de code daadwerkelijk verbeteren, zonder gebruik te maken van die "zwarte magie" die ontcijferd moet worden.

In een hypothetische Zen C zou dit zichtbaar zijn in beslissingen zoals bepaalde toepassingen van macro's of specifieke optimalisaties accepteren compilers die daadwerkelijk de prestaties verbeteren zonder de code onbegrijpelijk te maken.

10. Fouten mogen nooit genegeerd worden.

Deze richtlijn behandelt de afhandeling van uitzonderingen en fouten. Blokconstructies try/except volledig generiek dat gewoon doet pass Ze vormen een gegarandeerd recept voor moeilijk op te sporen problemen: er gaat iets mis, niemand merkt het, en maanden later duikt er ogenschijnlijk willekeurig gedrag op.

Zen adviseert dat, behalve in gevallen van zeer bewuste besluitvorming, fouten zichtbaar moeten worden gemaakt: dat alleen de bedoelde fouten worden vastgelegd en dat ze worden geregistreerd in logsDat Stuur duidelijke berichten. of zelfs de uitvoering stoppen als het systeem niet weet hoe het zich moet herstellen.

In C, Het systematisch negeren van retourcodes of het niet controleren op null-pointers. Het is een gegarandeerde manier om onderhoud in een nachtmerrie te veranderen.

11. Tenzij ze uitdrukkelijk het zwijgen zijn opgelegd.

Net als bij andere regels speelt nuance ook hier een rol. Er zijn situaties waarin je een specifieke fout kent, de gevolgen ervan hebt bestudeerd en vervolgens besluit dat... Het is niet cruciaal, en het is ook niet nodig dat je je op een gecontroleerde manier gedraagt.In dergelijke gevallen kan het redelijk zijn om hem expliciet het zwijgen op te leggen.

Een typisch voorbeeld zou zijn een vastleggen ValueError schrijf specifiek een debugbericht dat aangeeft dat het correct is afgehandeld.zonder de uitzondering verder uit te breiden. Het belangrijkste is echter dat het een bewuste en gedocumenteerde beslissing is, en geen manier om problemen te verdoezelen.

In C zou het equivalent zijn: Een bekende foutcode beheren door een gedocumenteerde standaardwaarde terug te geven.waarbij de gebeurtenis indien nodig wordt vastgelegd en de fout alleen in die context wordt genegeerd, zonder dat de applicatie vastloopt.

12. Wanneer je met onduidelijkheid wordt geconfronteerd, weersta dan de verleiding om te gissen.

Dit aforisme benadrukt een veelvoorkomende valkuil: het mentaal invullen van de gaten wanneer de eisen, het ontwerp of zelfs de code zelf onduidelijk zijn. Zen pleit voor... Verzin geen betekenissen waar die er niet zijn.Als iets onduidelijk is, is het het beste om een ​​expliciete beslissing af te dwingen.

In code vertaalt dat zich naar functienamen die precies uitleggen wat ze doen, commentaar dat belangrijke aannames verduidelijkt, en, het allerbelangrijkste, tests die het verwachte gedrag definiërenAls niet bekend is wat er moet gebeuren, zal de code gaan "gissen" en zal het vrijwel zeker fout zijn.

Wanneer dit principe wordt toegepast op een potentiële Zen C, fungeert het als een constante herinnering: Ga er niet van uit dat de compiler, het platform of de standaardbibliotheek doet wat je verwacht. zonder dit te hebben geverifieerd in de documentatie of door middel van concrete tests.

13. Er zou maar één voor de hand liggende manier moeten zijn om het te doen.

Dit principe vormt bijna de kern van de identiteit van Python. In tegenstelling tot motto's zoals dat van Perl ("Er zijn meer manieren om het te doen"), streeft Python ernaar ervoor te zorgen dat er voor een bepaalde taak, er is een duidelijk voorkeurspadDit vereenvoudigt het leerproces en zorgt ervoor dat code van verschillende mensen consistenter is.

Een klassiek voorbeeld is iteratie over reeksen. In Python wordt een zeer specifieke aanpak aanbevolen: for elemento in secuencia:In plaats van handmatige indexering af te dwingen, behalve wanneer nodig, maakt dit leeslussen bijna triviaal.

Voor C zou deze instelling zich kunnen vertalen in het op teamniveau adopteren van: Standaardpatronen voor terugkerende bewerkingenEen gangbare manier om arrays te doorlopen, geheugen te beheren of fouten af ​​te handelen, in plaats van dat elke ontwikkelaar zijn eigen stijl bedenkt.

14. Hoewel die methode in eerste instantie misschien niet voor de hand liggend lijkt (tenzij je Nederlands bent)

Dit aforisme bevat een knipoog: de voorkeursmethode is niet altijd meteen duidelijk. Vaak is het nodig om vertrouwd te raken met de taal, de bijbehorende bibliotheken en het ecosysteem voordat die "voor de hand liggende methode" natuurlijk aanvoelt.

De vermelding van de Nederlanders is een directe verwijzing naar Guido van Rossum, de bedenker van Python, die Nederlands is. Voor hem zijn veel ontwerpbeslissingen intuïtief, omdat hij precies weet wat hij voor ogen heeft; voor de rest is meer ervaring nodig. een periode van aanpassing en leren.

Iets soortgelijks zou gebeuren in elke informele "Zen C"-omgeving: wat voor ervaren gebruikers vanzelfsprekend lijkt (hoe je pointers gebruikt, hoe je headers organiseert, hoe je een project structureert) kan heel onduidelijk zijn voor iemand die nieuw is in de materie.

15. Nu is beter dan ooit, hoewel nooit vaak beter is dan nu.

Deze twee aforismen gaan over prioriteiten en timing. Enerzijds moedigen ze ons aan om niet te vervallen in besluiteloosheid door overmatig analyseren: Het is beter om redelijke vooruitgang te boeken dan niets te doen. Wachten op een perfect ontwerp dat nooit komt. Aan de andere kant dient het als een herinnering dat overhaaste veranderingen zonder nadenken tot nog grotere problemen kunnen leiden.

In code vertaalt dat zich naar Het vinden van de juiste balans tussen aan de slag gaan en niet zomaar structurele veranderingen improviseren zonder erover na te denken.Het is meestal geen goed idee om bepaalde cruciale taken voor onbepaalde tijd uit te stellen, maar het is ook niet verstandig om constant je werk te onderbreken om elk nieuw idee na te jagen.

De ideale aanpak is doorgaans om de evolutie van het systeem te beschouwen als een iteratief proces: voer meetbare veranderingen door en evalueer de impact ervanVerfijn… en houd een duidelijke takenlijst bij, zodat belangrijke zaken niet “voor altijd” blijven liggen.

16. Als de implementatie moeilijk uit te leggen is, is het een slecht idee.

Als je een ingewikkelde alinea nodig hebt om uit te leggen hoe een stuk code werkt, ligt het probleem waarschijnlijk niet bij je communicatieve vaardigheden, maar bij het ontwerp zelf. Dit gezegde moedigt aan om uitleg te gebruiken als middel om informatie over te brengen. ontwerp gezondheidstest.

Wanneer een implementatie zo complex is dat deze moeilijk in eenvoudige bewoordingen uit te leggen is, betekent dit meestal dat er... te veel tegenstrijdige verantwoordelijkhedenSlecht gedefinieerde afhankelijkheden of ondoordachte beslissingen zijn een teken dat refactoring raadzaam is voordat deze aanpak wordt geaccepteerd.

Dit criterium is zeer nuttig in zowel Python als C: Als je niet in een paar zinnen kunt uitleggen wat een functie of module doet, laat het me dan weten.Normaal gesproken is er ruimte voor structurele verbetering.

17. Als de implementatie gemakkelijk uit te leggen is, is het misschien een goed idee.

De keerzijde van het vorige punt is dat wanneer je een oplossing helder, bondig en rechtstreeks kunt beschrijven, je waarschijnlijk op de goede weg bent. Dat garandeert niet dat het idee perfect is, maar het is wel een goed teken dat je op de goede weg bent. De complexiteit is onder controle..

Dit principe sluit goed aan bij methoden zoals de "rubber duck-techniek": door hardop uit te leggen wat je code doet aan een andere persoon (of een levenloos object) kun je inconsistenties opsporen en bevestigen of iets goed doordacht is.

In een teamomgeving is het veel gemakkelijker om een ​​onderdeel van het systeem te beoordelen, te onderhouden en verder te ontwikkelen als elk teamlid na een korte uitleg snel begrijpt wat een stuk code doet.

18. Namespaces zijn een geweldig idee: laten we er meer van gebruiken.

Het laatste aforisme benadrukt het belang van namespaces als hulpmiddel voor het organiseren van code en het voorkomen van conflicten. In Python bieden modules, pakketten, klassen en functies verschillende organisatieniveaus. inkapseling en scheiding van verantwoordelijkheden.

Het consequent gebruiken van namespaces zorgt ervoor dat identificatoren met dezelfde naam in verschillende contexten kunnen bestaan ​​zonder conflicten, en helpt bij het groeperen van gerelateerde elementen onder één logische paraplu. Het uitbreiden van het gebruik van deze mechanismen leidt vaak tot meer modulaire architecturen.

In C, waar het naamruimtesysteem veel rudimentairder is, vertaalt dit idee zich in naamgevingsconventies, structurering door middel van header- en bronbestanden, en gedisciplineerd gebruik van static en voorvoegsels om botsingen te voorkomen. Een verstandige "Zen C" zou uitnodigen Beschouw elke module als een kleine, goed gedefinieerde naamruimte..

Vertalingen naar het Spaans en culturele nuances

In de loop der jaren zijn er verschillende Spaanse vertalingen van deze aforismen voorgesteld. Sommigen kiezen voor "Mooi is beter dan lelijk", anderen voor "Mooi is beter dan lelijk", enzovoort. Ze streven er allemaal naar de geest van het origineel te behouden, hoewel er onvermijdelijk enkele variaties ontstaan. nuances in stijl en woordkeuze kenmerkend voor de vertaler.

In het Spaans uit Spanje is het gebruikelijk om code te omschrijven als "mooi", "leesbaar" of "duidelijk", en van Vermijd "knoeiwerk" of "snelle lapmiddelen".Datzelfde idee ligt ten grondslag aan de oorspronkelijke Zen, die een serieuze toon vermengt met een vleugje humor, met name in het aforisme dat stelt dat de voor de hand liggende weg in eerste instantie misschien niet zo voor de hand liggend is "tenzij je Nederlands bent".

Deze vertalingen dienen er ook toe de tekst toegankelijker te maken voor mensen die niet vloeiend Engels spreken, zonder daarbij uit het oog te verliezen dat de principes van toepassing blijven. voor elke taal en elke ontwikkelaarsgemeenschapbuiten het Python-ecosysteem.

Is de Zen van Python een grap of een heilige regel?

Binnen de Python-gemeenschap zelf bestaat er enige discussie over de precieze status van Zen. Enerzijds wordt het in veel officiële documenten (PEP's) aangehaald als motivatie of rechtvaardiging van beslissingenEn in mailinglijsten van belangrijke ontwikkelaars wordt het gebruikt als argument voor of tegen specifieke voorstellen.

Aan de andere kant hebben sommige onderhoudsbedrijven erop gewezen dat een Zen-uitdrukking als wapen gebruiken (“Dit is in strijd met Zen, daarom is het slecht”) is niet altijd even logisch. Er zijn zelfs PEP's die opmerken dat bepaalde aforismen ooit werden geïnterpreteerd als kritiek op de taal zelf in haar beginjaren en niet letterlijk moeten worden genomen.

In werkelijkheid werkt Zen het beste als cultureel kompas en inspiratiebron wat een strikte ontwerpregel is. Python, met de tijdHet bevat functies (zoals toewijzing in expressies of patroonherkenning) die door sommigen als "complexer" worden beschouwd of minder in lijn met de oorspronkelijke eenvoud, maar die desondanks zijn overgenomen vanwege hun nut.

In die zin zou nadenken over een "Zen C" meer te maken hebben met algemene principes vastleggen die helpen om betere C-code te schrijven, zonder de bedoeling dat ze onbuigzame regels worden die elke evolutie van stijl of tools blokkeren.

Deze verzameling aforismen, vertalingen, voorbeelden en discussies vormt een soort mindmap van hoe wij "goede code" verstaan: leesbaar, zo eenvoudig mogelijk, expliciet in zijn intenties en doordacht gestructureerd. Of het nu in Python, C of een andere taal is, Het hanteren van die filosofie maakt vaak het verschil tussen een programma dat een worsteling is en een programma waar je met plezier aan werkt..