Zonder enige twijfel is programmeren moeilijk. Leren programmeren zonder al de stress Leren programmeren zonder alle stress Misschien heb je besloten om te blijven programmeren, of het nu voor een carrière is of gewoon als een hobby. Super goed! Maar misschien begin je je overweldigd te voelen. Niet zo goed. Hier is hulp om uw reis te vergemakkelijken. Lees verder . Het is één ding om talen te leren en algoritmen te bestuderen, maar het is een heel ander beest dat een complexe werktoepassing probeert te coderen waardoor je niet in de kou staat.
Op een bepaalde manier lijkt het schrijven van schone code veel op tekenen, koken of fotograferen 5 Creatieve hobby's die je een gelukkigere persoon zullen maken 5 Creatieve hobby's die je een gelukkiger persoon zullen maken Een goede creatieve uitlaatklep kan wonderen doen voor je geestelijke gezondheid en in het algemeen geluk. Hier zijn een paar creatieve hobby's waarvan bewezen is dat ze op deze manier helpen. Lees meer - het ziet er makkelijker uit dan het in werkelijkheid is. Dus waarom moeite doen? Nou, omdat de voordelen het waard zijn:
- Problemen worden gemakkelijker op te lossen. Zodra u begint te denken in schone code, verandert uw aanpak van het oplossen van problemen. In plaats van brute forcing-oplossingen 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 achterhalen van bepaalde segmenten en meer tijd aan het herstellen, herzien, uitbreiden, enzovoort.
- Ideeën worden duidelijker gecommuniceerd. Als u met andere programmeurs samenwerkt, vermindert opschonen code de waarschijnlijkheid van misverstanden tussen u allen, wat ook minder fouten op de lange termijn betekent.
Hier leest u hoe u 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 anders dan de interface tussen een programmeur en de onderliggende logica van een applicatie.
Dus als u onduidelijke en niet-beschrijvende namen gebruikt voor variabelen, klassen en functies, verdoezelt u in feite de toepassingslogica van elke programmeur die de code leest, inclusief uzelf.
"Ik ben geen geweldige programmeur; Ik ben gewoon een goede programmeur met geweldige gewoonten. "
- Kent Beck
Wat betekent een variabele met de naam dxy eigenlijk? Wie weet. Je zou waarschijnlijk het hele stuk code moeten lezen om de betekenis ervan te manipuleren. Aan de andere kant is de betekenis van een variabele zoals distanceBetweenXY direct herkenbaar.
Hetzelfde geldt voor klassen en functies. Neem geen genoegen met CalcTan() wanneer u in plaats daarvan kunt gaan voor CalculateTangent() of CalcTangentAngle() .
2. Geef elke klasse / functie één doel
Heb je ooit in een functie gekeken die honderden of zelfs duizenden regels lang was? Als je dat hebt gedaan, weet je hoeveel pijn het kan hebben om te bladeren, te begrijpen en te bewerken. Reacties kunnen helpen, maar slechts in beperkte mate.
"Programmeren is een grote onmogelijke taak doorbreken in verschillende kleine mogelijke taken."
- Jazzwant
Schone code wordt opgesplitst in atomaire chunks. Elke functie zou moeten streven naar één ding en elke klas zou moeten streven naar een bepaald concept. Dit is natuurlijk een vereenvoudiging, maar bij twijfel is eenvoudiger en schoner.
In de praktijk moet een complexe berekening zoals GetCreditScore() mogelijk worden onderverdeeld in verschillende GetCreditReports() zoals GetCreditReports(), ApplyCreditHistoryAge() en FilterOutstandingMarks() .
3. Verwijder onnodige code
Deze slechte gewoonte is er een waar ik nog steeds moeite mee heb met van tijd tot tijd. Het gebeurt meestal als volgt: ik wil een stuk code repareren of optimaliseren, dus ik geef het commentaar en herschrijf er vlak onder - en hoewel het werkt, bewaar ik de oude code daar voor het geval dat.
"Is het mogelijk dat software niet is zoals iets anders, dat het bedoeld is om te worden weggegooid: dat het in zijn geheel is om het altijd als een zeepbel te zien?"
- Alan J. Perlis
In de loop van de tijd verzamel ik een heleboel overduidelijke codeblokken die niet langer nodig zijn maar toch mijn bronbestanden volproppen. En het grappige is dat in veel gevallen de omringende code is geëvolueerd, zodat de code met commentaar niet zou werken, zelfs als deze werd hersteld.
Het probleem is dat deze manier om 'back-upcode' uit te spreken verouderd werd door bronbesturing. Als je iets als Git of Mercurial niet gebruikt, moet je meteen het bronbeheer gebruiken. Wat is Git en waarom zou je versiebeheer moeten gebruiken als je een ontwikkelaar bent Wat is Git en waarom zou je versiebeheer moeten gebruiken als je ' opnieuw een ontwikkelaar Als webontwikkelaar werken we vaak vaak op lokale ontwikkelsites en uploaden we vervolgens alles wanneer we klaar zijn. Dit is prima als je alleen bent en de veranderingen klein zijn, ... Lees meer. Schonere code wacht op u.
4. Leesbaarheid> Slimheid
Te veel programmeurs verwarren "schone code" met "slimme code", alsof het samenpersen van tien regels in één op een of andere manier schoner is. 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 in de eerste plaats twee keer zo moeilijk is als het schrijven van een programma. Dus als je zo slim bent als je kunt zijn als je het schrijft, hoe zal je het dan ooit debuggen? "
- Brian W. Kernighan
Ik denk dat programmeurs dol zijn op slimme code omdat het aanvoelt als een opgeloste puzzel of een raadsel. Ze vonden een speciale en unieke manier om iets te implementeren - een "kortere weg" als je dat wilt - en het fungeert bijna als een bevestiging van de vaardigheden van de programmeur.
Maar om schone code te schrijven, moet je je ego aan de deur laten.
Altijd de code optimaliseren voor de volgende persoon die deze gaat lezen, omdat naar alle waarschijnlijkheid de volgende persoon daadwerkelijk JOU gaat zijn en er niets schandelijks is dan dat je je eigen slimheid niet kunt lezen of begrijpen.
5. Houd een consistente coderingsstijl aan
Ik heb niets tegen goede programmeerlessen Wat maakt een goede programmeerhandleiding? Wat maakt een goede programmeerhandleiding? Niet alle programmeerinstructies zijn hetzelfde. Sommigen hebben er baat bij dat jij en anderen je tijd verspillen. Hier is wat u moet zoeken in een zelfstudie over kwaliteit. Read More, maar een van de nadelen is dat nieuwkomers uiteindelijk een breed scala aan tegenstrijdige gewoontes oppikken, vooral omdat ze betrekking hebben op codeerstijl.
Ik ben hier niet om te verklaren dat de ene stijl beter is dan de andere. Als je accolades op hun eigen manier wilt, ga ervoor. Als je wilt doorgaan met methode-aanroepen met spaties, prima. Als je liever tabbladen toevoegt aan 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 gecompliceerd.
Flat is beter dan genest.
Sparse is beter dan dicht.
De leesbaarheid telt.
- Tim Peters, De Zen van Python
Als u camelCaseNaming voor variabelen gaat gebruiken, mag u dit niet overspelen met underscore_naming . Als u GetThisObject() op één plaats gebruikt, ga dan niet verder met FetchThatObject() . En als je tabbladen en spaties combineert, verdien je het om je toetsenbord weg te laten halen.
Bepaal wat je vanaf het begin gaat doen en blijf hier door en door. Sommige talen, zoals Python en C #, hebben taalbrede stijlgidsen die u mogelijk wilt volgen.
6. Kies de juiste architectuur
Er zijn veel verschillende paradigma's en architecturen die u kunt gebruiken om uw projecten te maken. Merk op hoe deze tip gaat over het selecteren van de juiste voor uw behoeften, niet over het selecteren van de beste die er is. Er is geen "beste" hier.
"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 op dit moment erg populair in webontwikkeling, omdat het helpt om uw code zo te organiseren en te ontwerpen dat onderhoud zo minimaal mogelijk is.
Het Entity-Component-System (ECS) -patroon is op dit moment erg populair in de ontwikkeling van games, omdat het helpt bij het modulariseren van gamegegevens en logica op een manier die het onderhoud gemakkelijker maakt, en dit terwijl het allemaal code produceert die gemakkelijker te lezen is.
7. Leer de idiomatische uitdrukkingen van de taal beheersen
Een van de problemen bij het beheersen van een nieuwe programmeertaal 7 Nuttige trucs voor het beheersen van een nieuwe programmeertaal 7 Nuttige trucs voor het beheersen van een nieuwe programmeertaal Het is goed om overweldigd te zijn wanneer je leert programmeren. Je zult dingen waarschijnlijk zo snel vergeten als je ze leert. Deze tips kunnen u helpen om al die nieuwe informatie beter te bewaren. Meer lezen leert de nuances die het scheiden van alle andere talen. Deze nuances kunnen het verschil zijn tussen lelijke, ingewikkelde code en mooie, gemakkelijk te onderhouden code.
Overweeg Python, Java en JavaScript. Ze zijn allemaal extreem verschillend van elkaar, tot op zekere hoogte die een andere manier van denken vereist, afhankelijk van de taal die je kiest te gebruiken .
"Een taal die de manier waarop je denkt over programmeren niet beïnvloedt, is het niet waard om te weten."
- Alan J. Perlis
Waar Python draait om compacte code en eendtypen, is Java eerder gericht op breedsprakigheid en expliciteit. Elke taal heeft idiomen (zoals lijstbegrippen in Python) die een bepaalde manier van coderen aanmoedigen. Je zou er goed aan doen ze te leren.
Er zijn ook "anti-patronen" om je zorgen over te maken, die in wezen suboptimale ontwerppatronen zijn die resulteren in inefficiënte, onbetrouwbare of anderszins slechte code. Bestudeer en leer alle gemeenschappelijke anti-patronen af die gerelateerd zijn aan jouw taal naar keuze.
8. Bestudeer de code van meesters
Als je schone code wilt schrijven, kun je het beste doen om te zien hoe de schone code eruit ziet en proberen te begrijpen waarom het is - en er is geen betere manier om dit te doen dan door de bronbestanden van de industrie te bestuderen. meesters.
Vanzelfsprekend kun je niet zomaar in het hoofdkantoor van Microsoft duiken en hun projecten bekijken, maar je kunt altijd bladeren door bekende opensourceprojecten. De broncode van een open-source app bekijken en bewerken De broncode weergeven en bewerken Of An Open-Source App Hoewel open source een goede keuze kan zijn, moet je ook investeren in de juiste community. GitHub is een van de beste plaatsen om dit te doen, niet alleen vanwege de enorme hoeveelheid ... Lees meer. Weet niet waar te 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 source-projecten bestaan. Waarom dragen mensen bij aan open source-projecten? 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 en vaak veiliger te gebruiken is. Maar wat dwingt ontwikkelaars om gratis code bij te dragen? Lees meer: zodat anderen van hen kunnen leren. En als u besluit bij te dragen aan een dergelijk project, kan dit het leerproces versnellen. 5 Projectideeën om u te helpen leren Programmering Snellere 5 projectideeën om u te helpen programmeren sneller te leren Er zijn een paar manieren om de leercurve voor programmeren te vereenvoudigen. Zorg dat je handen vies worden en leer sneller met zijprojecten die je op elk moment kunt starten. Speel rond met deze vijf. Lees verder .
Persoonlijk was de allereerste keer dat ik echt schone code zag wanneer ik het open source Python-project van een hobbyist tegenkwam. De code was zo overweldigend elegant dat ik bijna stopte met programmeren, maar uiteindelijk leerde ik veel.
9. Schrijf goede reacties
"Schrijf goede reacties" is het oudste advies in de wereld van programmeren. Zodra nieuwkomers kennis maken met opmerkingen, worden ze zelfs aangemoedigd om zo vaak als ze kunnen opmerkingen te maken.
Maar het voelt bijna alsof we te ver zijn gegaan in de tegenovergestelde richting. Met name nieuwkomers hebben de neiging om te veel commentaar te geven. Ze beschrijven dingen die niet moeten worden beschreven en missen het nut van wat een 'goede opmerking' eigenlijk is.
"Codeer altijd alsof de man die je code onderhoudt een gewelddadige psychopaat is die weet waar je woont."
- John Woods
Hier is een goede vuistregel: opmerkingen bestaan om uit te leggen WAAROM een stukje code bestaat in plaats van WAT de code ook daadwerkelijk doet. Als de code netjes genoeg is geschreven, moet deze duidelijk zijn wat hij doet - de opmerking zou licht moeten werpen op de intentie waarom het is geschreven.
Opmerkingen kunnen goed zijn voor waarschuwingen (dat wil zeggen: "verwijderen van dit zal A, B en C breken"), maar voor het grootste deel zouden dingen moeten worden onthuld die niet direct uit de code kunnen worden gehaald (dwz "gebruik deze parameter omdat X, Y, en Z ").
10. Refactor, Refactor, Refactor
Net zoals bewerken deel uitmaakt van het schrijfproces, is refactoring onderdeel van het coderingsproces. Een afkeer van refactoring is de snelste manier om te eindigen met niet-te handhaven code, dus in veel opzichten is dit eigenlijk de belangrijkste tip om te overwegen.
Kort gezegd is refactoring slechts een mooie term voor het opschonen van de code zonder het werkelijke gedrag ervan te beïnvloeden.
"Telkens wanneer ik moet nadenken om te begrijpen wat de code doet, vraag ik me af of ik de code kan refacteren om dat inzicht directer zichtbaar te maken."
- Martin Fowler, Refactoring: Verbetering van het ontwerp van bestaande code
Een beetje wijsheid die bij mij is gebleven, is het gezegde: "Geef geen commentaar op slechte code. Herschrijf het. "Zoals Fowler in het citaat hierboven uitlegt, als code ooit verwarrend genoeg lijkt om commentaar te geven, moet je het misschien zelfs refactoren.
Verder, als je stukjes code hier en daar tijdens je project bewerkt, laat de code dan altijd in een betere staat dan toen je hem voor het eerst vond . Het lijkt misschien een overlast in het moment, maar het loont zich op de lange termijn (en kan zelfs mentale burn-out voorkomen). Programmering Burnout: Hoe je verloren motivatie te herwinnen Burnout programmeren: hoe je verloren motivatie herwinnen Schrijven van al die regels code kan fysiek en emotioneel leeglopen, alles wat je nodig hebt om weer op te klimmen is het besef dat motivatie kan worden herwonnen.
Er is altijd iets nieuws om te leren
Een programmeur die leert hoe hij schone code moet schrijven, lijkt op een romanschrijfster die leert hoe ze schoon proza moet schrijven: er is geen goede manier om het op zich te doen, maar er zijn veel verkeerde manieren om het te doen, en het zal jaren te beheersen.
Sommige mensen hebben niet wat nodig is en eindigen uiteindelijk met programmeren voor goed 6 Tekens die je niet als programmeur beschouwt 6 Tekens die je niet als programmeur mag beschouwen Niet iedereen is een programmeur. Als je niet helemaal zeker bent dat je een programmeur moet zijn, zijn hier enkele aanwijzingen die je in de juiste richting kunnen wijzen. Lees meer - en dat is prima, want er zijn tal van andere technische taken waarvoor geen codering is vereist. Coderen is niet voor iedereen: 7 technische banen die je zonder kunt krijgen Coderen is niet voor iedereen: 7 technische banen die je zonder kunt krijgen Wees niet ontmoedigd als je deel wilt uitmaken van het technische veld - er zijn genoeg banen voor mensen die niet weten hoe ze moeten coderen! Lees verder .
Maar voor iedereen is schone code iets dat absoluut de moeite waard is om naar te streven, zelfs als het de rest van je leven kost om er te komen.
Hoe belangrijk is schone code voor jou? Welke regels volgt u om uw code schoon en georganiseerd te houden? Heb je nog andere stukjes wijsheid om te delen? Laat het ons weten in de comments hieronder!