Bruke PHP CodeSniffer Med WordPress Forstå Kode Lukt

Ofte er måten vi skriver kode på, avhengig av hvordan vi begynte med programmering.

For eksempel, hvis noen har en formell utdanning i databehandling, vil de trolig vite en rekke prinsipper som hindrer dem i å skrive dårlig kvalitetskode. Dette er ikke en regel, selvfølgelig, men en observasjon. 

På samme måte vil de som kommer inn i programmeringen alene, utenom en formell setting, ofte slutte å lære seg og lære av en rekke forskjellige ressurser. Noen ganger kan dette føre til problemer med typen kode som er skrevet.

Å være helt klar: Jeg sier ikke at en formell utdanning i databehandling trumper noen som lærer seg selv, eller omvendt. Noen fantastiske programmerere er de som er utdannet; andre er de som er selvlærte. Men den ene tingen begge har felles med hverandre er at de ikke er fritatt for å skrive kode lukter fra tid til annen.

I denne artikkelen skal vi ta et innledende titt på kode lukter. Vi skal undersøke hva de er, hvordan de ser ut, og hvordan de ofte manifesterer seg i det arbeidet vi gjør. Vi bruker PHP til våre eksempler.

I den andre delen av denne serien skal vi se på hvordan vi kan unngå å skrive kode lukter. Spesielt vil vi bruke PHP, et par verktøy og WordPress som et valgfritt miljø.

Men først, la oss få en introduksjon til kode lukter.

Hva er kode lukter?

Avhengig av hvilken type utvikler du spør, vil du sannsynligvis få en variant på følgende definisjon:

Kode lukt, også kjent som dårlig lukt, i programmeringskode, refererer til ethvert symptom i kildekoden til et program som muligens indikerer et dypere problem. 

Denne definisjonen er rett fra Wikipedia. Det er ikke dårlig, men det er ikke min favoritt å ta på emnet. I stedet kommer min favorittdefinisjon fra en flink og populær programmør kalt Martin Fowler. Du kan lese hele sin ta på emnet kode lukter i denne artikkelen, men jeg har destillert det ned til følgende punkter:

1. "En lang metode er et godt eksempel på dette - bare å se på koden og nesetrykket hvis jeg ser mer enn et dusin linjer med Java."
2. "Lukter er ikke iboende dårlige på egenhånd - de er ofte en indikator på et problem i stedet for selve problemet."
   
3. "Dataklasser (klasser med alle data og ingen oppførsel) er gode eksempler."
   

Hvis du ikke har lest artikkelen, slutter han med dette:

En av de fine tingene om lukter er at det er lett for uerfaren folk å oppdage dem, selv om de ikke vet nok for å vurdere om det er et reelt problem eller å rette dem. 

Og jeg tror det er en fantastisk setning fordi det betyr at dette emnet er perfekt plassert for de som er programmerere, men er ikke sikker på hvor du skal begynne når det gjelder å identifisere og adressere kode lukter.

Kort sagt, erfaring spiller ikke en stor rolle i dette. Det er sikkert at de som er mer erfarne, sannsynligvis vil identifisere lukter lettere (fordi de har sett flere av dem), men mindre erfarne utviklere skal kunne identifisere dem.

Har du eksempler?

Selvfølgelig når det gjelder et emne som kode lukter, er det ofte lettere å snakke om dem på abstrakt nivå at det er å faktisk gjøre noe med dem. Men det er ikke praktisk, og det er heller ikke aktuelt for vårt daglige arbeid.

Med det sagt, hvorfor ikke ta en titt på noen eksempler på kode lukter? Vi undersøker hvorfor de er problematiske og tilbyr deretter en løsning for hvordan lukten kan fjernes ved å refactoring koden.

Eksempel 1: Klare navnekonvensjoner

En av de enkleste kodene lukter å få øye på, når en programmerer har valgt å bruke uklare variable navn. Det er, i sammenheng med koden, det er ikke klart hva en bestemt variabel skal representere.

Jo, det er tider hvor dette er akseptabelt (som å bruke en Jeg i en til loop). Men i en lengre metode er det ikke helt det samme som til loop). 

For eksempel:

Gitt nok tid, ville vi sannsynligvis kunne finne ut hva dette gjør. For det første er det en relativt enkel metode. For det andre vil vi kunne lese gjennom variablene, blokkene og komme tilbake verdi for å få en bedre ide om hva som skjer.
Men hvis vi ønsker å skrive ren kode som er lettere å forstå som vi henviser til det eller en annen programmerer jobber med det, hjelper det med å bruke klare navngivningskonvensjoner alltid. Og den ovennevnte koden bruker ikke klare navngivningskonvensjoner.
I stedet la vi reflektere den slik at den ser slik ut:
Mye enklere å forstå, er det ikke?
Legg merke til at algoritmen selv ikke er endret, men funksjonen og variablene har. Dette har gjort at mye av en forskjell i å lese denne koden. Hvis du blir spurt om hva denne koden skal gjøre, kan vi enkelt si noe som:
Returnerer en rekke elementer merket som sanne fra en forhåndsdefinert rekke elementer.
Så mye som mulig, unngå å bruke generiske variabelnavn og bruk det som er det klareste alternativet for deg og dine jevnaldrende.
Eksempel 2: Hold deg tørt
I programmeringen ville du være hardpresset for å finne en utvikler som ikke hadde hørt om KISS eller DRY (du vet "ikke gjenta deg selv"). Til tross for dette, ofte vi gjøre gjenta oss selv. 
Dette er et tegn på at forsøk på å overholde DRY-prinsippene lander annerledes med ulike typer programmerere. Og det er greit! Det er ingen eneste måte å demonstrere hvordan man overholder dette prinsippet.
Men fordi det er flere måter å gjøre det på, kan vi gi et eksempel på hvordan det ikke skal se ut og hvordan det skal se ut.
Anta for det følgende eksemplet at vi har en funksjon som kalles save_post og den aksepterer to argumenter: et post-ID og en streng som representerer tittelen på innlegget. En kode lukt ville se noe ut som dette:
Men hvorfor skulle vi manuelt skrive ut en samtale til lagre post tre ganger? I stedet la vi sette opp en assosiativ array, iterate gjennom den, og deretter ringe metoden en gang per iterasjon.
 'Hello World!', 2 => 'Farvel verden!', 3 => 'Hva er denne nye verden?',]; foreach ($ post som $ post_id => $ post_title) save_post ($ post_id, $ post_title); 
Selv om man kalder metoden en gang er fin, kan metoden gjøres enda mer fleksibel ved at den aksepterer rekke innlegg som argument og forlater for hver sløyfe intakt, men det er egentlig ikke poenget med dette eksemplet.
Hvis du finner deg selv å lage samme metode, ring flere ganger i en funksjon, men med forskjellige parametere, kan du ha en kode lukt. Og hvis du gjør det, så se etter måter å refactor det slik at du ringer metoden bare en gang. 
Tross alt, vil du ikke gjenta deg selv.
Eksempel 3: Langparameterlister
En av de vanligste tingene som vi fortsetter å se i programmeringen, uavhengig av språket, er når en funksjon aksepterer et stort antall parametre. 
Ulike programmerere vil ha meninger om hva som er det ideelle antall parametere en funksjon skal akseptere, men jeg pleier å tenke tre (gi eller ta to, kanskje) er et godt tall.
Først, la oss ta en titt på hva en funksjon med en lang parameterliste vil se ut. Det er sannsynligvis ingen overraskelser i følgende kode, og det kan hende du har å gjøre med noe akkurat slik i et av dine nåværende prosjekter:
Legg merke til i eksempelet ovenfor, er vi ikke opptatt av implementeringen av funksjonen. I stedet er vi bekymret for hvor mange parametere det krever. Det er mye informasjon å sende, og det vil få metoden til å ringe at mye uglier, så vel.
Det går ikke engang på emnet verifikasjon og validering. Men jeg drar på det.
Hvordan kan denne ryddes opp? Personlig er jeg en fan av å lage klasser for å representere samlinger av informasjon som dette. For dette spesielle eksempelet kan vi ha en klasse som presenterer en persons kontaktinformasjon. Videre kan den personen være tilknyttet et kredittkortnummer. 
Detaljer om dette kunne håndheves ved hjelp av forretningslogikk andre steder i søknaden, men abstraksjonen ville se slik ut:
Denne refactoring, selv om den er liten, er den største vi har gjort i denne artikkelen. Legg merke til at vi har gjort følgende ting:
 
Opprettet a Kontaktinformasjon klasse som tillater oss å instantiere et objekt som inneholder all betalingsinformasjon for en person.
 
Opprettet a Betalingsinformasjon klasse som tillater oss å opprettholde kredittkort eller debetkortnummer for en person, samt andre detaljer knyttet til den betalingsmåten.
 
Opprettet en Rekkefølge klasse, plassert sende inn ordre Fungerer inne i den, omdøpt den til å sende inn (siden sende inn ordre ville være overflødig), og reduserte parameterlisten til to verdier: en forekomst av Kontaktinformasjon klasse og Betalingsinformasjon klasse).
 
For å være klart, håndterer dette eksemplet ikke bekreftelsen av tilknytning mellom kontaktinformasjon og betalingsinformasjon, og det viser heller ikke andre klasser som kan være nødvendige (for eksempel om betaling mislyktes for transaksjonen).
Men det er ikke meningen med øvelsen.
I stedet ser vi på kodelukten av lange parameterlister og hvordan vi kan redusere dem ved hjelp av praktiske, mer vedlikeholdbare metoder som er tilgjengelige for oss.
Når du skriver en funksjon eller ringer til en funksjon som krever et stort antall argumenter, se etter måter å refactor den funksjonen. Det vil gjøre kohesjonens kohesjon øke og lukten minker.
Konklusjon
Husk at eksemplene vi har sett på er bare det. Listen er på ingen måte fullstendig, men de er vanlige lukter som du sannsynligvis vil se i kode som du arbeider med eller til og med kode du skriver. Jeg blir den første til å innrømme at jeg er skyldig i dette.
I tillegg er det mange, mange ressurser som er tilgjengelige når det gjelder å identifisere og fikse kode lukter. Heldigvis har vi også en rekke verktøy til disposisjon som vil hjelpe oss med å finne dem automatisk og rydde dem opp.
Og det er der vi er på vei neste. Spesielt skal vi bruke PHP CodeSniffer for å hjelpe oss med å unngå kode lukter i vår kode. Deretter skal vi se hvordan å innlemme WordPress-reglene i PHP CodeSniffer og koble den til vår IDE valg.
Som nevnt tidligere i denne artikkelen vil neste artikkel i serien fokusere mer på kode lukter når du skriver kode for WordPress. Vi tar en titt på noen verktøy og ressurser som er tilgjengelige for å sikre at vi unngår kode lukter, og for å sikre at vi skriver sterkere kode.
I mellomtiden kan du studere eksemplene ovenfor og sjekke ut de ressursene jeg har gitt som de er gode steder å lære mer om lukter og kode refactoring fra folk og steder som er bemerkelsesverdige innen vår bransje.
Husk at du kan fange alle mine kurs og opplæringsprogrammer på min profilside, og du kan følge meg på bloggen min og / eller Twitter på @tommcfarlin hvor jeg snakker om ulike programvareutviklingspraksis og hvordan vi kan bruke dem i WordPress.
Ikke nøl med å legge igjen noen spørsmål eller kommentarer i feedet under, og jeg vil sikte på å svare på hver av dem.



		
			
	   
	




Kode