Din kode kan lugte! Sådan rettes det

EN kode lugt er en del af kode eller et generelt kodningsmønster, der ser ud som om det kan indikere et dybere problem i den samlede struktur og design af en kodebase.

Tænk på en kodeluft, da ethvert tegn, der antyder, at et afsnit af koden skal refaktorificeres. Det er ikke, at koden er buggy eller ikke-funktionel - ofte kører ildelugtende kode helt fint - men ildelugtende kode er ofte svært at vedligeholde og udvide, hvilket kan føre til tekniske problemer (især på større projekter).

I denne artikel vil vi fremhæve 10 af de mest almindelige lugtkoder, hvad man skal kigge efter, og hvordan deodoriseres. Hvis du er en ny programmør Sådan lærer du programmering uden al stress Sådan lærer du programmering uden al stress Måske har du besluttet at fortsætte programmering, hvad enten det drejer sig om en karriere eller bare som en hobby. Store! Men måske begynder du at blive overvældet. Ikke så stor. Her er hjælp til at lette din rejse. , undgå disse, og din kode bliver mærkbar bedre!

1. Stram kobling

Problemet
Stram kobling er, når to objekter er så afhængige af hinandens data og / eller funktioner, at ændring af den ene kræver ændring af den anden. Når to objekter er for tæt koblet, kan det være et mareridt at foretage ændringer i kode, og det er mere sandsynligt, at du introducerer fejl ved hver ændring.

For eksempel:

klasse Arbejder Cykelcykel = ny Cykel (); offentlig ugyldig pendling () bike.drive (); 

I dette tilfælde er Arbejder og Bike tæt koblet. Hvad hvis du en dag ville køre en bil i stedet for en cykel til din pendling? Du bliver nødt til at gå ind i Arbejderklassen og udskifte al cykelrelateret kode med bilrelateret kode. Det er rodet og tilbøjelig til fejl.

Løsningen
Du kan løsne koblingen ved at tilføje et lag abstraktion. I dette tilfælde ønsker Arbejderklassen ikke kun at køre Cykler, men også Biler, og måske Trucks, muligvis endda Scootere. Dette er alle køretøjer, ikke? Så opret en køretøjsgrænseflade, som giver dig mulighed for at indsætte og udskifte forskellige køretøjstyper efter ønske:

klasse Arbejder Køretøjskøretøj; offentlig tomrumsændringVogn (køretøj v) køretøj = v;  offentlig ugyldig pendling () vehicle.drive ();  interface Køretøj void drive ();  klasse Cykel implementerer køretøj public void drive ()  class Car implementerer Vehicle public void drive () 

2. Gud objekter

Problemet
Et Gud-objekt er massiv klasse / modul, der indeholder for mange variabler og funktioner. Det “ved for meget” og “gør for meget,” hvilket er problematisk af to grunde. For det første bliver andre klasser / moduler overdrevent afhængige af denne til data (tæt kobling). For det andet bliver programmets overordnede struktur mudret, da alt klemmes på samme sted.

Løsningen
Tag et Gud-objekt, adskil dets data og funktioner i henhold til hvilke problemer de findes for at løse, og vend derefter disse grupperinger til objekter. Hvis du har et Guds objekt, kan det være bedre som en sammensætning af mange mindre objekter.

Antag f.eks., At du har en uhyrlig brugerklasse:

klasse Bruger offentligt Streng-brugernavn; offentlig strengadgangskode; offentlig streng adresse; offentlig streng-postnummer; public int age;… public String getUsername () return username;  offentligt ugyldigt sætUsnavn (streng u) brugernavn = u; 

Du kan konvertere det til en sammensætning af følgende:

klasse bruger legitimationsoplysninger; Profilprofil;… klasse legitimationsoplysninger offentlig String-brugernavn; offentlig strengadgangskode;… offentlig streng getUsnavn () return username;  offentligt ugyldigt sætUsnavn (streng u) brugernavn = u; 

Næste gang du skal ændre loginprocedurer, behøver du ikke gennemgå en massiv brugerklasse, fordi Credentials-klassen er mere håndterbar!

3. Lange funktioner

Problemet
En lang funktion er nøjagtigt, hvordan det lyder: en funktion, der er vokset for længe. Der er ikke et specifikt nummer for hvor mange kodelinjer der er “for langt” for en funktion er det en af ​​de ting, hvor du kender den, når du ser den. Det er stort set en strammere version af God-objektproblemet - en lang funktion har for mange ansvarsområder.

Løsningen
Lange funktioner skal opdeles i mange underfunktioner, hvor hver underfunktion er designet til at håndtere en enkelt opgave eller et problem. Ideelt set vil den originale lange funktion blive til en liste over underfunktionsopkald, hvilket gør koden renere og lettere at læse.

4. Overdrevne parametre

Problemet
En funktion (eller klassekonstruktør), der kræver for mange parametre, er problematisk af to grunde. For det første gør den koden mindre læsbar og gør det sværere at teste. Men for det andet og vigtigere kan det indikere, at formålet med funktionen er for tvetydig og forsøger at håndtere for mange ansvarsområder.

Løsningen
Mens “for mange” er subjektiv for en parameterliste, anbefaler vi at være på vagt over for enhver funktion, der har mere end 3 parametre. Sikker på, nogle gange er det fornuftigt at have en enkelt funktion med 5 eller endda 6 parametre, men kun hvis der er en rigtig god grund til det.

Det meste af tiden er der ikke en, og koden ville være bedre til at opdele denne funktion i to eller flere forskellige funktioner. I modsætning til “Lange funktioner” kodeluft, denne kan ikke løses bare ved at erstatte kode med underfunktioner - selve funktionen skal opdeles og opdeles i separate funktioner, der dækker separate ansvarsområder.

5. Dårligt navngivne identifikatorer

Problemet
En- eller to-bogstavs variabelnavne. Navn på ikke-beskrivende funktioner. Alt for prydede klassebetegnelser. Markering af variabelnavne med deres type (f.eks. B_isTælles for en boolesk variabel). Og værst af alt, at blande forskellige navneprogrammer gennem en enkelt kodebase. Alle disse resulterer i en vanskelig at læse, vanskelig at forstå og vanskelig at vedligeholde kode.

Løsningen
At vælge gode navne på variabler, funktioner og klasser er en hårdlært færdighed. Hvis du tilslutter dig et eksisterende projekt, skal du kamme det igennem og se, hvordan eksisterende identifikatorer navngives. Hvis der er en stilguide, skal du huske den og overholde den. Ved nye projekter skal du overveje at danne din egen stilguide og holde dig til den.

Generelt skal variabelnavne være korte, men beskrivende. Funktionsnavne skal typisk have mindst et verb, og det skal straks være indlysende, hvad funktionen gør lige ud fra dens navn, men undgå at indsætte for mange ord. Det samme gælder klassens navne.

6. Magiske numre

Problemet
Du gennemser en eller anden kode, som (forhåbentlig) en anden har skrevet, og du ser nogle hårdkodede numre. Måske er de en del af en if-statement, eller måske en del af nogle arkane beregninger, der ikke synes at give mening. Du skal ændre funktionen, men du kan bare ikke forstå, hvad tallene betyder. Cue hoved ridser.

Løsningen
Når du skriver kode, disse såkaldte “magiske numre” bør undgås for enhver pris. Hårdkodede tal giver mening på det tidspunkt, de er skrevet, men de kan hurtigt miste al mening - især når en anden forsøger at bevare din kode.

En løsning er at efterlade kommentarer, der forklarer antallet, men den bedre mulighed er at konvertere magiske numre til konstante variabler (til beregninger) eller optællinger (for betingede udsagn og switch-sætninger). Ved at give magiske numre et navn, bliver kode uendeligt mere læsbar på et øjeblik og mindre tilbøjelig til buggy-ændringer.

7. Deep Nesting

Problemet
Der er to hovedmåder til at ende med dybt indlejret kode: løkker og betingede udsagn. Dybt indlejret kode er ikke altid dårlig, men kan være problematisk, fordi det kan være svært at analysere (især hvis variabler ikke er navngivet godt) og endda hårdere at ændre.

Løsningen
Hvis du finder dig selv at skrive en dobbelt, tredobbelt eller endda firedoblet for-loop, kan din kode muligvis prøve at nå for langt uden for sig selv for at finde data. Giv i stedet en måde, hvorpå dataene kan anmodes om via et funktionsopkald på det objekt eller modul, der indeholder dataene.

På den anden side er dybt indlejrede betingede udsagn ofte et tegn på, at du prøver at håndtere for meget logik i en enkelt funktion eller klasse. Faktisk har dyb indlejring og lange funktioner en tendens til at gå hånd i hånd. Hvis din kode har massive switch-udsagn eller indlejrede if-then-annars-udsagn, kan du i stedet implementere et statsmaskine- eller strategimønster.

Dyb indlejring er især udbredt blandt uerfarne spilprogrammører 5 Gratis spiludviklingssoftwareværktøjer til at lave dine egne spil 5 Gratis spiludviklingssoftwareværktøjer til at lave dine egne spil Gratis spiludviklingssoftware er en god måde at starte videospilfremstilling. Vi har samlet den bedste spilsoftware på markedet. !

8. Uhåndterede undtagelser

Problemet
Undtagelser er magtfulde, men misbruges let. Lazy programmører, der forkert bruger throw-catch-udsagn, kan gøre fejlsøgning eksponentielt sværere, hvis ikke umulige. For eksempel at ignorere eller begrave fangede undtagelser.

Løsningen
I stedet for at ignorere eller begrave fangede undtagelser, skal du i det mindste udskrive undtagelsens stakespor, så debuggers har noget at arbejde med. At tillade dit program at svigte tavs er en opskrift på fremtidige hovedpine, garanteret! Foretrækker også at fange specifikke undtagelser frem for generelle undtagelser. Lær mere i vores artikel om, hvordan man håndterer undtagelser på den rigtige måde Sådan håndteres Java-undtagelser på den rigtige måde Sådan håndteres Java-undtagelser på den rigtige måde I denne artikel lærer du, hvad Java-undtagelser er, hvorfor de er vigtige, hvordan man brug dem og almindelige fejl at undgå. .

9. Duplikatkode

Problemet
Du udfører den samme nøjagtige logik i flere ikke-relaterede områder af dit program. Senere indser du, at du er nødt til at ændre denne logik, men kan ikke huske alle de steder, hvor du implementerede den. Du ender med at ændre det kun 5 ud af 8 steder, hvilket resulterer i buggy og inkonsekvent opførsel.

Løsningen
Duplikatkode er en primær kandidat til at blive omdannet til en funktion. Lad os f.eks. Sige, at du udvikler en chat-applikation, og at du skriver dette:

String queryUsname = getSomeUsername (); boolsk isUserOnline = falsk; til (Streng-brugernavn: online-brugere) if (username.equals (queryUsname))) isUserOnline = true;  if (isUserOnline) …

Et andet sted i koden indser du, at du er nødt til at udføre det samme “er denne bruger online?” kontrollere. I stedet for at kopiere klistret på loopen, kan du trække den ud til en funktion:

public boolean isUserOnline (String queryUsername) for (String username: onlineUsers) if (username.equals (queryUsername))) return true;  returner falsk; 

Nu hvor som helst i din kode kan du bruge isUserOnline () -check. Hvis du nogensinde har brug for at ændre denne logik, kan du justere metoden, og den vil gælde overalt, den kaldes.

10. Manglende kommentarer

Problemet
Koden har absolut ingen kommentarer overalt. Ingen dokumentationsblokke til funktioner, ingen brugsoversigter for klasser, ingen forklaringer på algoritmer osv. Man kan muligvis hævde, at velskrevet kode ikke har brug for kommentarer, men sandheden er, at selv den bedst skrevne kode stadig tager mere mental energi til forstå end engelsk.

Løsningen
Målet med en let at vedligeholde codebase skal være kode, der er skrevet godt nok til at det ikke gør det brug for kommentarer, men har dem stadig. Og når du skriver kommentarer, skal du sigte mod kommentarer, der forklarer hvorfor der findes et kodestykke i stedet for at forklare hvad det gør. Kommentarer er gode for sjælen og sundheden. Forsøm ikke dem.

Hvordan man skriver kode, der ikke lugter

Så åbenlyst som det kan se ud, skyldes de fleste kodelugt fra en misforståelse eller forsømmelse af gode programmeringsprincipper og mønstre. 10 Grundlæggende programmeringsprincipper Hver programmerer skal følge 10 grundlæggende programmeringsprincipper Hver programmerer skal følge Skriv altid kode, der kan vedligeholdes af alle, der kan slutte op med at arbejde på din software. Med henblik herpå er her flere programmeringsprincipper, der hjælper dig med at rydde op i din handling. . For eksempel eliminerer en solid overholdelse af DRY-princippet mest kodeduplicering, mens beherskelse af princippet om enkeltansvar gør det næsten umuligt at skabe uhyggelige gudsgenstande.

Vi anbefaler også at læse vores artikel om, hvordan du skriver renere kode 10 tip til skrivning af renere & bedre kode 10 tip til skrivning af renere og bedre kode At skrive ren kode ser lettere ud, end det faktisk er, men fordelene er det værd. Her er, hvordan du kan begynde at skrive renere kode i dag. , der ser på en mere praktisk side af programmeringen. Hvis du ikke kan læse din egen kode og forstå den med et øjeblik, hvordan vil nogen derpå? Ren kode er lugtfri kode.

Hvad kæmper du mest med, når det kommer til programmering? Del med os ned i kommentarerne nedenfor!

Billedkredit: SIphotography / Depositphotos