Din kode kan luke! Slik løser du det

EN kode lukt er en del av kode eller generelt kodende mønster som ser ut som det kan tyde på et dypere problem i den generelle strukturen og utformingen av en kodebase.

Tenk på en kode lukt som et tegn som antyder en del av koden skal refactored. Det er ikke at koden er buggy eller ikke-funksjonell - ofte stinker stinkende kode ganske bra - men stinkende kode er ofte vanskelig å vedlikeholde og utvide, noe som kan føre til tekniske problemer (spesielt på større prosjekter).

I denne artikkelen vil vi markere 10 av de vanligste kodelukene, hva du skal se etter, og hvordan du deodoriserer dem. Hvis du er en ny programmerer Slik lærer du programmering uten all stress Slik lærer du programmering uten all stress Kanskje du har bestemt deg for å forfølge programmering, enten for en karriere eller bare som en hobby. Flott! Men kanskje du begynner å føle deg overveldet. Ikke så bra. Her er hjelp til å lette reisen din. Les mer, unngå disse, og koden din blir merkbart bedre!

1. Stram kobling

Problemet
Tett kobling er når to objekter er så avhengige av hverandres data og / eller funksjoner som endrer en krever modifisering av den andre. Når to objekter er for tett koblet, kan endringer i kode være et mareritt, og du er mer sannsynlig å introdusere feil med hver forandring.

For eksempel:

klassearbeider motorsykkel = ny sykkel (); offentlig tomgang pendle () bike.drive (); 

I dette tilfellet er arbeideren og sykkelen tett koblet sammen. Hva om en dag du ville kjøre en bil i stedet for en sykkel for pendling? Du må gå inn i arbeiderklassen og erstatte all sykkelrelatert kode med bilrelatert kode. Det er rotete og utsatt for feil.

Løsningen
Du kan løsne koblingen ved å legge til et lag av abstraksjon. I dette tilfellet ønsker arbeiderklassen ikke bare å kjøre sykler, men også biler, og kanskje lastebiler, muligens til og med scootere. Dette er alle kjøretøy, er de ikke? Så opprett et Vehicle-grensesnitt, som lar deg sette inn og erstatte forskjellige kjøretøytyper etter ønske:

klassearbeideren kjøretøybil; offentlig ugyldig forandringVehicle (Vehicle v) vehicle = v;  public void commute () vehicle.drive ();  grensesnitt Vehicle void drive ();  klasse Sykkelredskaper Kjøretøy offentlig tomgangstasjon ()  klasse Bilredskaper Kjøretøy offentlig tomgangstasjon () 

2. Guds gjenstander

Problemet
Et Guds objekt er massiv klasse / modul som inneholder for mange variabler og funksjoner. Den “vet for mye” og “gjør for mye,” som er problematisk av to grunner. For det første blir andre klasser / moduler altfor avhengige av dette for data (tett kopling). For det andre blir den generelle strukturen av programmet slamete, ettersom alt blir crammed inn på samme sted.

Løsningen
Ta en Guds gjenstand, skille dataene og funksjonene i henhold til hvilke problemer de eksisterer for å løse, og slå disse grupperinger inn i objekter. Hvis du har en Guds gjenstand, kan det være bedre som en sammensetning av mange mindre gjenstander.

For eksempel, anta at du har en uheldig brukerklasse:

klassen bruker public string brukernavn; offentlig strengpassord offentlig streng adresse; offentlig strekk postnummer; offentlig int alder; ... offentlig String getUsername () return brukernavn;  Offentlig tomt sett Brukernavn (String u) brukernavn = u; 

Du kan konvertere den til en sammensetning av følgende:

klassen bruker legitimasjon legitimasjon; Profilprofil; ... klassegrupper public String brukernavn; offentlig String passord; ... offentlig String getUsername () return brukernavn;  Offentlig tomt sett Brukernavn (String u) brukernavn = u; 

Neste gang du må endre påloggingsprosedyrer, trenger du ikke å gjennomsøke gjennom en massiv brukerklasse fordi klassen Credentials er mer håndterbar!

3. lange funksjoner

Problemet
En lang funksjon er akkurat det det høres ut som: en funksjon som har vokst for lenge. Mens det ikke er et spesifikt tall for hvor mange linjer med kode er “for lenge” For en funksjon er det en av de tingene du vet når du ser den. Det er ganske mye en strengere versjon av Guds objektproblem - en lang funksjon har for mange ansvarsområder.

Løsningen
Langfunksjoner bør brytes inn i mange underfunksjoner, der hver delfunksjon er utformet for å håndtere en enkelt oppgave eller et problem. Ideelt sett vil den opprinnelige lange funksjonen bli en liste over underfunksjonsanrop, noe som gjør koden renere og enklere å lese.

4. Overdreven Parametre

Problemet
En funksjon (eller klassekonstruktør) som krever for mange parametere, er problematisk av to grunner. For det første gjør koden mindre lesbar og gjør det vanskeligere å teste. Men for det andre, og enda viktigere, kan det tyde på at formålet med funksjonen er for tvetydig og forsøker å håndtere for mange ansvarsområder.

Løsningen
Samtidig som “for mange” er subjektiv for en parameterliste, anbefaler vi å være forsiktig med enhver funksjon som har mer enn 3 parametere. Sikker, noen ganger er det fornuftig å ha en enkelt funksjon med 5 eller til og med 6 parametere, men bare hvis det er en veldig god grunn til det.

Mesteparten av tiden er det ikke en og koden ville være bedre å bryte den funksjonen i to eller flere forskjellige funksjoner. i motsetning til “Lange funksjoner” kode lukt, denne løsningen kan ikke løses bare ved å bytte kode med underfunksjoner - selve funksjonen må deles og deles i separate funksjoner som dekker eget ansvar.

5. Dårlige navngitte identifikatorer

Problemet
En- eller to bokstavs variable navn. Ikke-beskrivende funksjonsnavn. Altfor utsmykket klassenavn. Merking av variable navn med deres type (for eksempel b_isCounted for en boolsk variabel). Og verst av alt, bland forskjellige navneordninger i en enkelt kodebase. Alt dette resulterer i vanskelig å lese, vanskelig å forstå og vanskelig å vedlikeholde kode.

Løsningen
Å plukke gode navn på variabler, funksjoner og klasser er en hardt lært ferdighet. Hvis du slutter seg til et eksisterende prosjekt, kan du kaste gjennom det og se hvordan eksisterende identifikatorer heter. Hvis det er en stilguide, husk det og hold deg til det. For nye prosjekter, vurder å lage din egen stilguide og hold deg til den.

Generelt bør variabel navn være kort, men beskrivende. Funksjonsnavn skal vanligvis ha minst ett verb, og det bør umiddelbart være klart hva funksjonen gjør bare fra sitt navn, men unngå å cramming i for mange ord. Det samme gjelder for klassenavn.

6. Magic Numbers

Problemet
Du blar gjennom noen kode som (forhåpentligvis) noen andre skrev, og du ser noen hardkodede tall. Kanskje de er en del av en if-setning, eller kanskje en del av noen baneberegninger som ikke synes å være fornuftige. Du må endre funksjonen, men du kan bare ikke forstå hva tallene betyr. Cue hodet skraper.

Løsningen
Når du skriver kode, disse såkalte “magiske tall” bør unngås for enhver pris. Hardkodede tall gir mening når de er skrevet, men de kan raskt miste all mening - spesielt når noen andre prøver å opprettholde koden din.

En løsning er å legge igjen kommentarer som forklarer tallet, men det bedre alternativet er å konvertere magiske tall til konstante variabler (for beregninger) eller tall (for betingede setninger og bryteretninger). Ved å gi magiske tall et navn, blir koden uendelig mer lesbar med et blikk og mindre utsatt for buggy endringer.

7. Deep Nesting

Problemet
Det er to hoved måter å ende opp med dypt nestet kode: looper og betingede utsagn. Dypt nestet kode er ikke alltid dårlig, men kan være problematisk fordi det kan være vanskelig å analysere (spesielt hvis variabler ikke heter godt) og enda tøffere å modifisere.

Løsningen
Hvis du finner deg selv å skrive en dobbel, tredobbelt eller til og med firemannsforløp, så kan koden din forsøke å nå for langt utenfor seg selv for å finne data. I stedet gi en måte at dataene kan bli forespurt gjennom et funksjonsanrop på hvilket objekt eller modul som inneholder dataene.

På den annen side er dypt nestede betingede utsagn ofte et tegn på at du prøver å håndtere for mye logikk i en enkelt funksjon eller klasse. Faktisk pleier dype og lange funksjoner å gå hånd i hånd. Hvis koden din har massive bryterklæringer eller nestede if-then-else-setninger, kan du kanskje implementere et statlig maskin- eller strategimønster i stedet.

Deep nesting er spesielt utbredt blant uerfarne spillprogrammerere 5 Gratis spillutviklingsprogramvareverktøy for å lage dine egne spill 5 Gratis spillutviklingsprogramvareverktøy for å lage dine egne spill Her er den beste gratis spillutviklingsprogramvaren og verktøyene du kan bruke til å begynne å lage ditt drømmespill i dag. Les mer !

8. Uhåndterte unntak

Problemet
Unntak er kraftige men enkelt misbrukt. Lazy programmerere som feilaktig bruker kasteopptak, kan gjøre debugging eksponentielt vanskeligere, om ikke umulig. For eksempel ignorerer eller begraver fangede unntak.

Løsningen
I stedet for å ignorere eller begrave fangede unntak, skriv ut det minste unntakets stakkespor slik at debuggere har noe å jobbe med. Tillat programmet å svikte tykt er en oppskrift på fremtidige hodepine, garantert! Også, foretrekker å fange spesifikke unntak fra generelle unntak. Lær mer i vår artikkel om hvordan du håndterer unntak på riktig måte Slik håndterer du Java-unntak på riktig måte Hvordan håndterer du Java-unntak på riktig måte I denne artikkelen lærer du hvilke Java-unntak, hvorfor de er viktige, hvordan bruk dem, og vanlige feil å unngå. Les mer .

9. Duplikat kode

Problemet
Du utfører samme nøyaktige logikk i flere uavhengige områder av programmet. Senere innser du at du må endre den logikken, men husk ikke alle stedene der du implementerte den. Du ender med å endre den på bare 5 av 8 steder, noe som resulterer i buggy og inkonsekvent oppførsel.

Løsningen
Duplikat kode er en førstekandidat for å bli omgjort til en funksjon. For eksempel, la oss si at du utvikler et chat-program, og du skriver dette:

String queryUsername = getSomeUsername (); boolsk isUserOnline = false; for (String brukernavn: onlineUsers) if (brukernavn.equals (queryUsername)) isUserOnline = true;  hvis (isUserOnline) ...

Et annet sted i koden, skjønner du at du må utføre det samme “er denne brukeren på nettet?” kryss av. I stedet for å kopiere klistremerkeren kan du trekke den ut i en funksjon:

offentlig boolean isUserOnline (String queryUsername) for (String brukernavn: onlineUsers) if (brukernavn.equals (queryUsername)) return true;  returnere false; 

Nå hvor som helst i koden din, kan du bruke isUserOnline () sjekk. Hvis du noen gang trenger å endre denne logikken, kan du justere metoden, og den vil gjelde overalt den heter.

10. Mangel på kommentarer

Problemet
Koden har absolutt ingen kommentarer hvor som helst. Ingen dokumentasjonsblokker for funksjoner, ingen oversikt over bruk av klasser, ingen forklaringer på algoritmer, etc. Man kan hevde at velskrevet kode ikke trenger kommentarer, men sannheten er at selv den best skrevne koden fortsatt tar mer mental energi til forstå enn engelsk.

Løsningen
Målet med en enkel å vedlikeholde kodebase skal være kode som er skrevet godt nok til at den ikke gjør det trenge kommentarer, men har fortsatt dem. Og når du skriver kommentarer, tar du sikte på kommentarer som forklarer Hvorfor en kodebit finnes i stedet for å forklare hva det gjør det. Kommentarer er gode for sjelen og sunnheten. Ikke forsøm dem.

Hvordan skrive kode som ikke lukter

Så tydelig som det kan virke, kommer de fleste kode luktene fra en misforståelse eller forsømmelse av gode programmeringsprinsipper og mønstre. 10 Grunnleggende programmeringsprinsipper Hver programmerer må følge 10 Grunnprogrammeringsprinsipper Hver programmerer må følge Skriv alltid kode som kan vedlikeholdes av alle som kan ende opp arbeidet med programvaren din. Til dette formål er det flere programmeringsprinsipper for å hjelpe deg med å rydde opp i handlingen. Les mer . For eksempel eliminerer en solid etterlevelse av DRY-prinsippet de fleste kod duplisering, mens mestring av single responsibility-prinsippet gjør det nesten umulig å skape monstrous gud gjenstander.

Vi anbefaler også å lese vår artikkel om hvordan du skriver renere kode 10 Tips for å skrive renere og bedre kode 10 Tips for å skrive renere og bedre kode Skrive ren kode ser enklere ut enn det egentlig er, men fordelene er verdt det. Slik kan du begynne å skrive renere kode i dag. Les mer, som ser på en mer praktisk side av programmeringen. Hvis du ikke kan lese din egen kode og forstå det på et øyeblikk, hvordan vil noen andre? Ren kode er luktfri kode.

Hva sliter du mest med når det gjelder programmering? Del med oss ​​ned i kommentarene nedenfor!

Bildekreditt: SIphotography / Depositphotos

Utforsk mer om: Programmering.