10 tips voor het schrijven van schonere en betere code

Advertentie

Programmeren is zonder twijfel moeilijk. Het is één ding leer talen en studeer algoritmen, maar het is een heel ander beest dat een complexe werkende applicatie probeert te coderen, waardoor je niet je ogen uit wilt kijken.

In zekere zin lijkt het schrijven van schone code veel op tekenen, koken of fotografie - het ziet er gemakkelijker uit dan het in werkelijkheid is. Dus waarom moeite doen? Welnu, omdat de voordelen het waard zijn:

• Problemen worden gemakkelijker op te lossen. Zodra u begint te denken in schone code, verandert uw benadering van het oplossen van problemen. In plaats van brute oplossingen te forceren, worden uw algoritmen en softwareontwerp eleganter en opzettelijk.
• Er wordt minder tijd verspild aan onderhoud. Schone code is gemakkelijker te lezen en te begrijpen, dus u besteedt minder tijd aan het uitzoeken wat bepaalde segmenten eigenlijk doen en meer tijd aan repareren, herzien, uitbreiden, enz.
• Ideeën worden duidelijker gecommuniceerd. Als je met andere programmeurs werkt, verkleint schone code de kans op misverstanden tussen jullie allemaal, wat op de lange termijn ook minder bugs betekent.
  instagram viewer

Hier is hoe JIJ kunt beginnen met het schrijven van schone code.

1. Gebruik beschrijvende namen

Wat zijn variabelen, klassen en functies? Er zijn veel manieren om dat te beantwoorden, maar als je er echt over nadenkt, zijn die dingen niets meer dan de interface tussen een programmeur en de onderliggende logica van een applicatie.

Dus als je onduidelijke en niet-beschrijvende namen gebruikt voor variabelen, klassen en functies, u verdoezelt in wezen de applicatielogica van elke programmeur die de code leest, inclusief jezelf.

"Ik ben geen geweldige programmeur; Ik ben gewoon een goede programmeur met geweldige gewoonten. "
- Kent Beck

Wat heet een variabele dxy eigenlijk? Wie weet. Je zou waarschijnlijk het hele stuk code moeten lezen om de betekenis ervan te reverse-engineeren. Aan de andere kant de betekenis van een variabele zoals distanceBetweenXY is direct herkenbaar.

Hetzelfde geldt voor klassen en functies. Neem geen genoegen met CalcTan () waar je voor kunt gaan CalculateTangent () of CalcTangentAngle () in plaats daarvan.

2. Geef elke klasse / functie één doel

Heb je ooit een kijkje genomen in een functie die honderden of zelfs duizenden regels lang was? Als je dat hebt, dan weet je hoeveel pijn het kan zijn om te bladeren, te begrijpen en te bewerken. Opmerkingen kunnen helpen, maar slechts in beperkte mate.

"Programmeren is één grote onmogelijke taak opsplitsen in verschillende kleine mogelijke taken."
- Jazzwant

Schone code is opgesplitst in atoombrokken. Elke functie moet gericht zijn op één ding en elke klas moet gericht zijn op één bepaald concept. Dit is natuurlijk een vereenvoudiging, maar bij twijfel is eenvoudiger schoner.

In de praktijk is een complexe berekening zoals GetCreditScore () moet mogelijk worden onderverdeeld in verschillende hulpfuncties, zoals GetCreditReports (), ApplyCreditHistoryAge (), en FilterOutstandingMarks ().

3. Verwijder onnodige code

Deze slechte gewoonte is er een waar ik van tijd tot tijd nog steeds mee worstel. Het gebeurt meestal als volgt: ik wil een stuk code repareren of optimaliseren, dus ik becommentarieer het en herschrijf het er net onder - en hoewel het werkt, bewaar ik de oude code voor het geval dat.

"Is het mogelijk dat software niet als iets anders is, dat het bedoeld is om te worden weggegooid: dat het er juist om gaat om het altijd als een zeepbel te zien?"
- Alan J. Perlis

In de loop van de tijd verzamel ik een heleboel uitgepakte codeblokken die niet langer nodig zijn, maar mijn bronbestanden overbelasten. En het grappige is dat in veel gevallen de omringende code is geëvolueerd, zodat de uitgecommenteerde code niet zou werken, zelfs niet als deze zou worden hersteld.

Het punt is dat deze praktijk van het uitcommenten van "back-upcode" door broncontrole achterhaald was. Als je zoiets als Git of Mercurial niet gebruikt, moet je dat doen begin meteen met bronbeheer. Er wacht u een schonere code.

Onthoud dat het ook belangrijk is om te voorkomen dat u repetitieve code schrijft, wat u gemakkelijk kunt bereiken met een webframework. Hier zijn een paar web frameworks die het waard zijn om te leren als ontwikkelaar 5 Web Frameworks die het leren waard zijn voor ontwikkelaarsGeïnteresseerd in het leren van geavanceerde webontwikkeling? Vermijd het schrijven van repetitieve code, gebruik in plaats daarvan deze webontwikkelingskaders. Lees verder .

4. Leesbaarheid> Slimheid

Te veel programmeurs verwarren 'schone code' met 'slimme code', alsof het op de een of andere manier schoner is om tien regels samen te voegen tot één. Natuurlijk neemt het minder ruimte in beslag op het scherm, maar is het eigenlijk gemakkelijker te begrijpen? Soms misschien. Maar meestal? Nee.

“Iedereen weet dat debuggen twee keer zo moeilijk is als het schrijven van een programma in de eerste plaats. Dus als u zo slim bent als u kunt zijn wanneer u het schrijft, hoe gaat u het dan ooit debuggen? "
- Brian W. Kernighan

Ik denk dat programmeurs dol zijn op slimme code omdat het voelt als een opgeloste puzzel of raadsel. Ze vonden een speciale en unieke manier om iets te implementeren - een 'snelkoppeling' als je wilt - en het dient bijna als een validatie van de vaardigheden van de programmeur.

Maar om schone code te schrijven, moet je je ego aan de deur achterlaten.

Optimaliseer altijd de code voor de volgende persoon die het gaat lezen, want naar alle waarschijnlijkheid is dat de volgende persoon wordt JIJ eigenlijk en er is niets zo beschamend dan niet in staat te zijn om die van jezelf te lezen of te begrijpen slimheid.

5. Houd een consistente coderingsstijl aan

ik heb niets tegen goede programmeer tutorials Wat is een goede programmeerhandleiding?Niet alle programmeerlessen zijn gelijk gemaakt. Sommigen profiteren ervan en anderen verspillen uiteindelijk uw tijd. Hier is waar u op moet letten in een tutorial over kwaliteitsprogrammering. Lees verder , maar een van de nadelen is dat nieuwkomers uiteindelijk een grote verscheidenheid aan tegenstrijdige gewoonten oppikken, vooral omdat ze betrekking hebben op coderingsstijl.

Ik ben hier niet om te verklaren dat de ene stijl beter is dan de andere. Als je beugels op hun eigen lijnen wilt, ga ervoor. Als je methodeaanroepen met spaties wilt voorafgaan, prima. Als je liever tabs gebruikt dan spaties, laat me je dan niet anders overtuigen.

Maar wat je ook doet, blijf consistent!

Mooi is beter dan lelijk.
Expliciet is beter dan impliciet.
Eenvoudig is beter dan complex.
Complex is beter dan ingewikkeld.
Flat is beter dan genest.
Schaars is beter dan dicht.
Leesbaarheid telt.
- Tim Peters, De zen van Python

Als je gaat gebruiken camelCaseNaming voor variabelen, vervals het niet met onderstrepingsteken. Als je gebruikt GetThisObject () op één plek, ga niet mee FetchThatObject () ergens anders. En als u tabs en spaties combineert, verdient u het om uw toetsenbord te laten verwijderen.

Bepaal wat u vanaf het begin gaat doen en blijf er door en door bij. Sommige talen, zoals Python en C #, hebben taalbrede stijlgidsen die je misschien wilt volgen.

6. Kies de juiste architectuur

Er zijn veel verschillende paradigma's en architecturen die u kunt gebruiken om uw projecten te creëren. Merk op hoe deze tip gaat over het selecteren van de Rechtsaf een voor uw behoeften, niet over het selecteren van de het beste een daar. Er is hier geen "beste".

"Zonder vereisten en ontwerp is programmeren de kunst om bugs toe te voegen aan een leeg tekstbestand."
- Louis Srygley

Het Model-View-Controller (MVC) -patroon is bijvoorbeeld momenteel erg populair in webontwikkeling omdat het helpt om uw code georganiseerd en ontworpen te houden op een manier die onderhoudsinspanningen minimaliseert.

Evenzo is het Entity-Component-System (ECS) -patroon op dit moment erg populair in game-ontwikkeling omdat het helpt bij het modulariseren van gamegegevens en logica op een manier die het onderhoud eenvoudiger maakt, terwijl het tegelijkertijd code produceert die gemakkelijker te beheren is lezen.

7. Beheers de idioom van de taal

Een van de moeilijkheden in een nieuwe programmeertaal beheersen 7 Handige trucs voor het beheersen van een nieuwe programmeertaalHet is prima om overweldigd te worden als je leert programmeren. U vergeet de dingen waarschijnlijk net zo snel als u ze leert. Deze tips kunnen u helpen om al die nieuwe informatie beter te bewaren. Lees verder leert de nuances die het van alle andere talen scheiden. Deze nuances kunnen het verschil zijn tussen lelijke, ingewikkelde code en mooie, gemakkelijk te onderhouden code.

Overweeg Python, Java en JavaScript. Ze verschillen allemaal enorm van elkaar, in een mate die een andere manier van denken, afhankelijk van de taal die u kiest.

"Een taal die de manier waarop je over programmeren denkt niet beïnvloedt, is het niet waard om te weten."
- Alan J. Perlis

Terwijl Python alles te maken heeft met compacte code en typen van eend, is Java meer in de richting van breedsprakigheid en explicietheid. Elke taal heeft idioom (zoals lijstbegrip in Python) die een bepaalde manier van coderen aanmoedigen. Je doet er goed aan om ze te leren.

Er zijn ook 'antipatronen' waar u zich zorgen over moet maken. Dit zijn in wezen suboptimale ontwerppatronen die resulteren in inefficiënte, onbetrouwbare of anderszins slechte code. Bestudeer en leer alle gebruikelijke antipatronen af ​​die verband houden met uw taal naar keuze.

8. Bestudeer de Code of Masters

Als u schone code wilt schrijven, kunt u het beste zien hoe schone code eruit ziet en proberen begrijp waarom het zo is - en er is geen betere manier om dit te doen dan door de bronbestanden van te bestuderen meesters in de industrie.

Het is duidelijk dat je niet zomaar het hoofdkantoor van Microsoft kunt binnenlopen en naar hun projecten kunt kijken, maar dat kan altijd blader door bekende open-sourceprojecten Hoe de broncode van een open source-app te bekijken en te bewerkenHoewel open source een goede keuze is, moet u ook investeren in de juiste community. GitHub is een van de beste plaatsen om dit te doen, niet alleen vanwege de enorme hoeveelheid ... Lees verder . Weet je niet waar je moet beginnen? Probeer de tentoongestelde projecten op Github.

'Elke dwaas kan code schrijven die een computer kan begrijpen. Goede programmeurs schrijven code die mensen kunnen begrijpen. '
- Martin Fowler, Refactoring: verbetering van het ontwerp van bestaande code

Dat is tenslotte een van de redenen waarom open-sourceprojecten bestaan Waarom dragen mensen bij aan open source-projecten?Open source ontwikkeling is de toekomst van software. Het is geweldig voor gebruikers omdat open source-software meestal gratis beschikbaar is en vaak veiliger in gebruik. Maar wat dwingt ontwikkelaars om gratis code bij te dragen? Lees verder : zodat anderen van hen kunnen leren. En als je besluit om bij te dragen aan zo'n project, het kan het leerproces versnellen 5 Projectideeën om u te helpen sneller te leren programmerenEr zijn een paar manieren om de leercurve voor programmeren te vergemakkelijken. Maak je handen vuil en leer sneller met zijprojecten die je op elk moment kunt starten. Speel met deze vijf. Lees verder .

Persoonlijk was de allereerste keer dat ik echt schone code zag, toen ik een open-source Python-project van een bepaalde hobbyist tegenkwam. De code was zo overweldigend elegant dat ik bijna stopte met programmeren, maar het heeft me uiteindelijk veel geleerd.

9. Schrijf goede opmerkingen

"Schrijf goede opmerkingen" is het oudste advies in de programmeerwereld. Zodra nieuwkomers kennis maken met reacties, worden ze zelfs aangemoedigd om zo vaak mogelijk te reageren.

Maar het voelt bijna alsof we te ver in de tegenovergestelde richting zijn gezwaaid. Vooral nieuwkomers hebben de neiging te veel te reageren - ze beschrijven dingen die niet hoeven te worden beschreven en missen het punt van wat een 'goede reactie' eigenlijk is.

'Codeer altijd alsof de man die uiteindelijk je code onderhoudt een gewelddadige psychopaat zal zijn die weet waar je woont.'
- John Woods

Hier is een goede vuistregel: er zijn opmerkingen om uit te leggen WAAROM een stuk code bestaat in plaats van WAT de code eigenlijk doet. Als de code netjes genoeg is geschreven, moet hij duidelijk zijn wat hij doet - de opmerking moet licht werpen op de bedoeling achter waarom hij is geschreven.

Opmerkingen kunnen goed zijn voor waarschuwingen (d.w.z. 'als u dit verwijdert, worden A, B en C verbroken'), maar voor het grootste deel zou dat moeten ontdek dingen die niet onmiddellijk uit de code kunnen worden gehaald (d.w.z. gebruik deze parameter omdat X, Y en Z ”).

10. Refactor, Refactor, Refactor

Net zoals bewerken onderdeel uitmaakt van het schrijfproces, is refactoring onderdeel van het coderingsproces. Een afkeer van refactoring is de snelste manier om met onhoudbare code te eindigen, dus in veel opzichten is dit eigenlijk de belangrijkste tip om te overwegen.

Kortom, refactoring is slechts een mooie term voor het opschonen van de code zonder het daadwerkelijke gedrag te beïnvloeden.

"Telkens als ik moet nadenken om te begrijpen wat de code doet, vraag ik me af of ik de code kan herstructureren om dat begrip duidelijker te maken."
- Martin Fowler, Refactoring: verbetering van het ontwerp van bestaande code

Een stukje wijsheid dat me is bijgebleven, is het gezegde: 'Geef geen commentaar op slechte code. Herschrijf het. ' Zoals Fowler in het bovenstaande citaat uitlegt, als code ooit zo verwarrend aanvoelt dat je er commentaar op moet geven, moet je hem misschien eigenlijk refacteren.

Bovendien, terwijl je hier en daar stukjes code bewerkt tijdens je project, laat de code altijd in een betere staat achter dan toen u hem voor het eerst vond. Het lijkt op het moment misschien hinderlijk, maar het zal op de lange termijn zijn vruchten afwerpen (en kan zelfs mentale burn-out voorkomen Burn-out programmeren: hoe u uw verloren motivatie terugkrijgtHet schrijven van al die regels code kan fysiek en emotioneel uitputtend zijn. Het enige dat je nodig hebt om weer op te staan, is het besef dat motivatie kan worden teruggewonnen. Lees verder ).

Er valt altijd iets nieuws te leren

Een programmeur die leert schone code te schrijven, lijkt op een romanschrijver die schoon proza ​​leert schrijven: er is niet per se een goede manier om het te doen, maar er zijn genoeg verkeerde manieren om het te doen, en het zal jaren duren meester.

Sommige mensen hebben niet wat er nodig is en uiteindelijk voorgoed stoppen met programmeren 6 tekenen dat u niet bedoeld bent om programmeur te zijnNiet iedereen is bedoeld als programmeur. Als u niet helemaal zeker weet of u programmeur wilt worden, volgen hier enkele aanwijzingen die u in de goede richting kunnen wijzen. Lees verder - en dat is prima, want er zijn er genoeg andere technische banen zonder codering Codering is niet voor iedereen: 9 technische banen die u zonder kunt krijgenWees niet ontmoedigd als u deel wilt uitmaken van het technische veld. Er zijn genoeg banen voor mensen zonder codeervaardigheden! Lees verder . Maar voor iedereen is schone code iets dat absoluut de moeite waard is om naar te streven, ook al duurt het de rest van je leven om daar te komen.