Din kod kan luktas! Hur man fixar det

en kod lukt är en bit av kod eller generellt kodningsmönster som ser ut som det kan indikera ett djupare problem i den övergripande strukturen och utformningen av en kodbas.

Tänk på en kodlukt som ett tecken som föreslår att en sektion kod ska refactoreras. Det är inte så att koden är buggy eller icke-funktionell - ofta stinker den stinkande koden bara bra - men stinkande kod är ofta svår att underhålla och förlänga, vilket kan leda till tekniska problem (speciellt vid större projekt).

I den här artikeln kommer vi att markera 10 av de vanligaste kodluktarna, vad man ska leta efter och hur deodoriseras. Om du är en ny programmerare Så här läser du Programmering utan all stress Hur man lär sig programmering utan all stress Kanske har du bestämt dig för att fortsätta programmera, vare sig du är en karriär eller bara som en hobby. Bra! Men kanske börjar du känna dig överväldigad. Inte så bra. Här är hjälp för att underlätta din resa. Läs mer, undvik dessa och din kod blir märkbart bättre!

1. Stram koppling

Problemet
Stram koppling är när två objekt är så beroende av varandras data och / eller funktioner som modifierar krävs att modifiera den andra. När två objekt är för hårt kopplade, kan ändringar i kod vara en mardröm och du är mer benägna att införa buggar med varje förändring.

Till exempel:

klassarbetare cykelcykel = ny cykel (); public void commute () bike.drive (); 

I detta fall är arbetare och cykel tätt kopplade. Vad händer om du en dag ville köra bil istället för en cykel för din pendling? Du måste gå in i arbetarklassen och ersätta all cykelrelaterad kod med bilrelaterad kod. Det är rörigt och benäget för fel.

Lösningen
Du kan lossa kopplingen genom att lägga till ett lager av abstraktion. I detta fall vill arbetarklassen inte bara köra cyklar, utan även bilar, och kanske lastbilar, eventuellt även skotrar. Det här är alla fordon, eller hur? Så skapa ett Vehicle-gränssnitt, där du kan infoga och ersätta olika fordonstyper efter behov:

klassarbetare Fordonsfordon; allmän tomrumsbyte fordon (fordon v) fordon = v;  public void commute () vehicle.drive ();  gränssnitt Vehicle void drive ();  klass Bike redskap Vehicle public void drive ()  klass Bilutrustning Fordon public void drive () 

2. Guds objekt

Problemet
Ett Gudsobjekt är massiv klass / modul som innehåller för många variabler och funktioner. Det “vet för mycket” och “gör för mycket,” vilket är problematiskt av två skäl. För det första blir andra klasser / moduler alltför beroende av denna för data (tätt koppling). För det andra blir programmets övergripande struktur mudlig, eftersom allt blir hopfällt till samma ställe.

Lösningen
Ta ett gudobjekt, skilda data och funktioner i enlighet med vilka problem de finns för att lösa, och vrid dessa grupperingar till objekt. Om du har ett gudobjekt kan det vara bättre som en sammansättning av många mindre objekt.

Antag förmodligen att du har en monstrous Användarklass:

klass användare Public String användarnamn; offentligt stränglösenord allmän strängadress allmän sträng postnummer; public int age; ... public String getUsername () returnera användarnamn;  public void setSername (String u) username = u; 

Du kan konvertera den till en sammansättning av följande:

klass användare credentials credentials; Profilprofil; ... klassuppgifter (public String användarnamn; Public String lösenord; ... public String getUsername () return användarnamn;  public void setSername (String u) username = u; 

Nästa gång du behöver ändra inloggningsprocedurer behöver du inte krypa igenom en massiv användarklass, eftersom klassen Credentials är hanterbar!

3. Långfunktioner

Problemet
En lång funktion är exakt vad det låter som: en funktion som har blivit för lång. Medan det inte finns ett visst tal för hur många rader kod är “för länge” För en funktion är det en av de sakerna där du känner det när du ser det. Det är ganska mycket en strängare version av Guds objektproblem - en lång funktion har för många ansvarsområden.

Lösningen
Långa funktioner bör brytas upp i många delfunktioner, där varje delfunktion är utformad för att hantera en enda uppgift eller ett problem. Idealiskt kommer den ursprungliga långa funktionen att bli en lista över subfunktionssamtal, vilket gör koden renare och lättare att läsa.

4. Överdrivena parametrar

Problemet
En funktion (eller klasskonstruktor) som kräver för många parametrar är problematisk av två skäl. För det första gör den kod mindre läsbar och gör det svårare att testa. Men för det andra, och ännu viktigare, kan det tyda på att syftet med funktionen är för tvetydigt och försöker hantera för många ansvarsområden.

Lösningen
Medan “för många” är subjektiv för en parametrarlista rekommenderar vi att vara försiktig med någon funktion som har mer än 3 parametrar. Visst, ibland är det meningsfullt att ha en enda funktion med 5 eller till och med 6 parametrar, men bara om det finns en riktigt bra anledning till det.

För det mesta är det inte en och koden skulle vara bättre att bryta den funktionen i två eller flera olika funktioner. till skillnad från “Långa funktioner” kod lukt kan denna inte lösas genom att bara ersätta kod med delfunktioner - själva funktionen måste delas upp och delas upp i separata funktioner som täcker separata ansvarsområden.

5. Dåligt namngivna identifierare

Problemet
En- eller två bokstavs variabla namn. Ej beskrivna funktionsnamn. Överdrivet prydda klassnamn. Markerar variabla namn med deras typ (t ex b_isCounted för en boolesvariabel). Och värst av allt, blanda olika namngivningssystem i en enda kodbas. Alla dessa resulterar i svårläst, svårförståelig och svår att underhålla kod.

Lösningen
Att välja bra namn på variabler, funktioner och klasser är en svårlärd färdighet. Om du går med ett befintligt projekt, kamma igenom det och se hur befintliga identifierare heter. Om det finns en stilguide, memorera det och hålla fast vid det. För nya projekt, överväga att skapa din egen stilguide och hålla fast vid den.

I allmänhet bör variabla namn vara kort men beskrivande. Funktionsnamn ska normalt ha minst ett verb, och det ska vara omedelbart uppenbart vad funktionen gör just från sitt namn, men undviker krympning i alltför många ord. Samma gäller för klassnamn.

6. Magic Numbers

Problemet
Du bläddrar igenom någon kod som (förhoppningsvis) någon annan skrev och du upptäcker några hårdkodade nummer. Kanske är de en del av ett if-uttalande, eller kanske en del av några böjliga beräkningar som inte verkar vara meningsfulla. Du behöver ändra funktionen, men du kan bara inte förstå vad siffrorna betyder. Cue huvudet kliar.

Lösningen
När du skriver kod, dessa så kallade “magiska tal” bör undvikas till varje pris. Hårdkodade siffror är meningsfulla när de skrivs, men de kan snabbt förlora all mening - speciellt när någon annan försöker behålla din kod.

En lösning är att lämna kommentarer som förklarar numret, men det bättre alternativet är att konvertera magiska tal till konstanta variabler (för beräkningar) eller uppräkningar (för villkorliga uttalanden och omkopplingsdeklarationer). Genom att ge magiska nummer ett namn blir koden oändligt mer läsbar vid en blick och mindre benägna att buggy ändras.

7. Deep Nesting

Problemet
Det finns två huvudsakliga sätt att sluta med djupt nestad kod: loopar och villkorliga uttalanden. Djupt nestad kod är inte alltid dålig, men kan vara problematisk eftersom det kan vara svårt att analysera (speciellt om variabler inte heter bra) och även svårare att modifiera.

Lösningen
Om du tycker att du skriver en dubbel, trippel eller till och med fyrdubblad för-loop, så kan din kod försöka nå för långt utanför sig själv för att hitta data. I stället ger ett sätt att de data som begärs via ett funktionssamtal på vilket objekt eller modul som helst innehåller data.

Å andra sidan är djupt nestade villkorliga uttalanden ofta ett tecken på att du försöker hantera för mycket logik i en enda funktion eller klass. Faktum är att djupa häckar och långa funktioner tenderar att gå hand i hand. Om din kod har massiva omkopplingsdeklarationer eller kapslade if-then-else-uttalanden kanske du vill implementera ett statligt maskin- eller strategimönster istället.

Deep nesting är särskilt utbredd bland oerfarna spelprogrammerare 5 Gratis spelutvecklingsprogramverktyg för att skapa dina egna spel 5 Gratis spelutvecklingsprogramverktyg för att skapa egna spel Här är den bästa gratis spelutvecklingsprogramvaran och verktyg du kan använda för att börja göra ditt drömspel i dag. Läs mer !

8. Obehandlade undantag

Problemet
Undantag är kraftfulla men lätt missbrukas. Lata programmerare som använder felaktiga uttalanden kan göra felsökning exponentiellt hårdare, om inte omöjlig. Till exempel, ignorera eller begrava fångade undantag.

Lösningen
I stället för att ignorera eller begrava fångade undantag, skriv ut minst undantagets stackspår så att debuggers har något att arbeta med. Tillåter ditt program att misslyckas tyst är ett recept på framtida huvudvärk, garanterat! Också föredra att fånga specifika undantag från allmänna undantag. Läs mer i vår artikel om hur man hanterar undantag på rätt sätt Hur man hanterar Java-undantag på rätt sätt Hur man hanterar Java-undantag på rätt sätt I den här artikeln lär du dig vilka Java-undantag är, varför de är viktiga, hur man använd dem och vanliga misstag att undvika. Läs mer .

9. Kopieringskod

Problemet
Du utför samma exakta logik i flera orelaterade områden i ditt program. Senare inser du att du behöver ändra den logiken, men kommer inte ihåg alla platser där du implementerade den. Du hamnar ändå på bara 5 av 8 platser, vilket resulterar i buggy och inkonsekvent beteende.

Lösningen
Duplikatkod är en viktig kandidat för att bli en funktion. Låt oss till exempel säga att du utvecklar en chattprogram och skriver det här:

String queryUsername = getSomeUsername (); boolean isUserOnline = false; för (String användarnamn: onlineUsers) if (användarnamn.equals (queryUsername)) isUserOnline = true;  om (isUserOnline) ...

Någonstans annat i koden inser du att du behöver utföra samma sak “är den här användaren online?” kontrollera. I stället för att kopiera klistret i slingan kan du dra ut det i en funktion:

public boolean isUserOnline (String queryUsername) for (String användarnamn: onlineUsers) if (användarnamn.equals (queryUsername)) return true;  returnera false; 

Nu var som helst i din kod kan du använda isUserOnline () checken. Om du någonsin behöver ändra den här logiken kan du justera metoden och den kommer att tillämpas överallt den heter.

10. Brist på kommentarer

Problemet
Koden har absolut inga kommentarer någonstans. Inga dokumentationsblock för funktioner, inga användningsöversikter för klasser, inga förklaringar på algoritmer etc. Man kan argumentera för att välskriven kod inte behöver kommentarer, men sanningen är att även den bästa skrivna koden fortfarande tar mer mental energi till förstå än engelska.

Lösningen
Målet med en lättanpassad kodbas bör vara kod som skrivs tillräckligt bra att det inte gör det behöver kommentarer, men har fortfarande dem. Och när du skriver kommentarer, rikta dig till kommentarer som förklarar Varför ett koduttag finns istället för att förklara Vad det gör det. Kommentarer är bra för själen och sanningen. Försum inte dem.

Hur man skriver kod som inte luktar

Så tydligt som det kan tyckas uppstår de flesta kodluktar från ett missförstånd eller försummelse av goda programmeringsprinciper och mönster. 10 Grundläggande programmeringsprinciper Varje programmerare måste följa 10 Grundläggande programmeringsprinciper Varje programmerare måste följa Skriv alltid kod som kan upprätthållas av alla som kan sluta upp arbeta på din programvara. För detta ändamål finns här flera programmeringsprinciper för att hjälpa dig att rensa upp din handling. Läs mer . Till exempel eliminerar en fast vidhäftning till DRY-principen de flesta koddubblering, medan det är nästan omöjligt att förstå principen om enkelansvar.

Vi rekommenderar också att du läser vår artikel om hur du skriver renare kod 10 Tips för att skriva renare och bättre kod 10 Tips för att skriva renare och bättre kod Skriva ren kod ser lättare ut än vad den egentligen är, men fördelarna är värda det. Så här kan du börja skriva renare kod idag. Läs mer, som ser på en mer praktisk sida av programmeringen. Om du inte kan läsa din egen kod och förstå den en överblick, hur kommer någon annan? Ren kod är luktfri kod.

Vad kämpar du mest med när det gäller programmering? Dela med oss ​​ner i kommentarerna nedan!

Bildkrediter: SIphotography / Depositphotos

Utforska mer om: Programmering.