Mijn favoriete manieren om slechte Python te schrijven

Mijn favoriete manieren om slechte Python te schrijven

Heb je ooit naar code gekeken die je zes maanden of drie jaar geleden schreef, en jezelf afgevraagd: “Wat dacht ik in vredesnaam?” We hebben allemaal.

Nadenkend over mijn eigen Pythonic-gruwelen, heb ik een paar trends opgemerkt. Ik wil niet zeggen dat ze mijn “favorieten” zijn, maar ik schijn ze veel te doen:

Te complexe algoritmen

Dit is een grote. Ik kijk naar de code die ik heb geschreven – de klassen, modules, enz. – en kan zien dat het prima werkt.

Maar het kan VEEL eenvoudiger.

Eenvoudiger betekent vaak beter leesbaar, beter te onderhouden en – verrassend vaak – minder kwetsbaar. Ik bedoel, de code moet nog steeds correct werken. Maar correcte, eenvoudige code is bijna altijd beter dan correcte, complexe code.

Als ik een tijdje weg ga en later met frisse ogen naar de codebase kijk, zie ik vaak een veel schonere oplossing.

“Per ongeluk werkende” code

Deze is best grappig.

Als ik de code lees, kan ik zien wat ik op dat moment dacht. En het werkt echt – dat wil zeggen, het voldoet aan de vereisten, het doorstaat de unit-tests en het gedraagt ​​​​zich zoals het hoort.

Maar het is duidelijk dat toen ik die code schreef, ik het probleem dat ik aan het schrijven was om op te lossen totaal verkeerd begreep.

Echt, het zou NIET moeten werken. Omdat ik code aan het schrijven was om een ​​volledig fictief probleem op te lossen, niet het werkelijke probleem! Maar op de een of andere manier lost het beide op.

Ik geef toe dat ik me schaam dat dit gebeurt.

Toch ben ik verbaasd dat dit überhaupt gebeurt, en nog meer dat het herhaaldelijk lijkt te gebeuren.

Misleidende identificatienamen

Ik heb VEEL moeite gestoken in het kiezen van goede namen voor dingen. Variabelen, type- en klassenamen, methoden, modules, et cetera.

Dat komt omdat onze duidelijkheid over wat er aan de hand is, recht evenredig is met hoe duidelijk we de rol van elk onderdeel begrijpen. En het kiezen van goede namen voor al die mensen kan veel helpen.

Maar:

Ook al maak ik hier al jaren een prioriteit van, ik ga vaak terug om wat code te refactoren, of een nieuwe functie toe te voegen of zoiets, en denk: “Ik had dit echt SomeOtherName moeten noemen”.

Misschien is de les dat het verbeteren van de leesbaarheid een nooit eindigend proces is. We kunnen altijd verbeteren.

Missen

Deze is best interessant.

Wat ik heb gevonden, is dat ik kan kijken naar een codebasis die ik enige tijd geleden heb geschreven. En ik zal zien dat ik een techniek had kunnen gebruiken om de kwaliteit van de code echt te verbeteren. Maar dat deed ik niet.

Die ’techniek’ kan een ontwerppatroon zijn; een idioom; of misschien zelfs een kenmerk van de taal. Bijna altijd, gewoon omdat ik er toen nog niet van op de hoogte was.

Met mijn huidige wijsheid zou het een stuk makkelijker zijn geweest. En het zou waarschijnlijk robuuster, onderhoudbaarder, leesbaarder, enz.

Het mooie als je dit opmerkt: Het is een teken dat je verbeterd bent als programmeur.

Dus vier het wanneer je dit allemaal opmerkt en blijf ervan leren.

Bron: Aaron Maxwell

Affiliate Samenwerkingen
Berichten per categorie