Efter att ha läst “Clean Code” lärde jag mig detta

Funktioner

Ska vara liten

Små funktioner hjälper dig att berätta historien korrekt. De lägger till ordning, separering av bekymmer, korrekt abstraktion och korrekt struktur till din kod.

Om din funktion inte är liten följer den förmodligen inte andra viktiga principer som vi snart kommer att upptäcka. Små funktioner, när de heter rätt, gör koden tydlig, lätt att felsöka och enkel att följa.
Hur liten? Du kanske undrar. Tja, enligt författaren till Clean Code, Uncle Bob, ska en funktion aldrig vara mer än 20 rader kod.

Om det är, enligt Bob, kan du förmodligen dela upp det i en annan funktion. När det gäller det exakta antalet är jag säker på att det bara är en tumregel eller en röd flagga för att hålla oss uppmärksamma om vi skriver stora funktioner.

”Den första regeln för funktioner är att de måste vara små. Den andra regeln är att de måste vara mindre än så. ”

Gör en sak

Funktioner bör göra en sak, och bara en sak. Ibland är det mycket svårt att se till att funktionen bara gör en sak, men det är en viktig princip att se till att vi inte gör flera saker samtidigt. Bobs styre? Om det gör mer än en sak har du förmodligen 2 funktioner, inte en.

“Funktioner borde göra en sak. De borde göra det bra. De borde bara göra det”

Bör namnges korrekt

Alla funktioner gör åtgärder. det är syftet med dem – att fungera. Därför, när de heter funktioner, bör de ha verb som innebär vad de gör.

få, ställ in, spara, ta bort, ladda … du förstår kärnan i det, eller hur?

Ett vanligt undantag, som är allmänt känt, är dock ordet – att kontrollera om det är ett booleskt tillstånd.

Konventionen är att funktionen ska returnera en boolean angående tillståndet (inga överraskningar med fel förväntan). Så ett ogiltigt lösenord (lösenord) förväntas returnera en booleskt.

Bör minimera argument

Helst, ju mindre argument desto bättre. Men om vi vill göra våra funktioner återanvändbara och oberoende av någon annan affärslogik kan vissa argument behövas.

Därför är upp till 2 argument bra, 3 bör undvikas, och utöver det bjuds hårda sonderingar. Tanken bakom denna princip är att funktioner ändå är väldigt små, så om du behöver 3 argument som är avgörande för affärslogiken har troligen avkopplingen av den stora funktionen gjorts dåligt.

Betydelsen är att logiken är bunden för starkt, och kanske är separation i en annan punkt i koden bättre.

Skapa inte biverkningar

Funktioner bör inte ha några biverkningar eller konsekvenser för andra processer, utom dess huvudansvar. Som “Gör en sak” -regeln antyder, bör den inte göra något annat än den avsedda uppgiften att utföra.

Detta hjälper till att förhindra överraskningar, det är lättare att felsöka och hålla reda på exakt vad som gör vad.

Det rena sättet att skriva funktioner

Låt oss erkänna det. Det är mycket svårt att skriva funktioner som följer dessa principer vid vårt första försök. Vi kommer sannolikt att tänka om och göra mycket mer planering än vi behöver för att få det på vårt första försök.

Men sanningen är att den inte ska vara perfekt första gången vi skriver funktionen. Precis som i skrift har kodningen sina lager, utkast, förfiningar (refactoring) och utveckling tills den är skarp och blank. Farbror Bob uttrycker det vältaligt:

”Skriva mjukvara är som alla andra typer av skrivande. När du skriver ett papper eller en artikel får du ner tankarna först, sedan masserar du det tills det läser bra. Det första utkastet kan vara klumpigt och oorganiserat, gör du ord på det och omstrukturerar det och förfinar det tills det läser som du vill att det ska läsa ”

Pages: 1 2 3 4 5