Share
På dette nettstedet bruker vi mye tid deling informasjon og diskutere hvordan å utføre visse ting med WordPress. Tross alt, formålet med nettstedet er å gi opplæringsprogrammer - det vil si, vi forsøker å gi praktisk råd om hvordan du bygger visse ting ved hjelp av plattformen.
Men utvikling handler ikke bare om å skrive kode og bygge ting. Det handler også om å skrive kvalitet, vedlikeholdskode, refactoring og forbedre tilstanden til prosjektene våre, og generelt prøver å forlate en kodebase i en bedre tilstand enn det var da vi fant det (eller da vi begynte å lage det).
Så heller enn å fokusere på hvordan du bygger noe eller vurderer en bestemt kode, la oss se på noen få praktiske tips for å skrive kvalitet WordPress-kode.
Først og fremst - og selv om vi diskuterer dette mye - er det verdt å gjenta om og om igjen:
Følgende WordPress-kodingsstandarder er en av de viktigste tingene du kan gjøre når du skriver temaer, plugins eller programmer.
For de som ikke er kjent, gir WordPress Coding Standards regler for hvordan vi skal formatere vår WordPress-baserte PHP. Selvfølgelig er det ingenting å faktisk håndheve reglene - du kan ignorere dem (og mange gjør), men det regnes som en god praksis for de som ser på å utvikle WordPress-baserte prosjekter, og respekteres av de som er aktive i samfunnet.
Videre betyr følgende kodningsstandarder at vi - sammen med alle andre utviklere som også gjør det - vil ha lignende utseendekode. Faktisk er et av målene for definerte kodingsstandarder slik at koden ser ut som den er skrevet av en enkelt utvikler.
En annen fordel ved å gjøre dette er at det også gjør det enkelt for andre å bidra til vår kodebase. Tross alt, siden WordPress og dets avledede verk er åpen kildekode, kan andre kanskje komme sammen og gaffel eller bidra til å gi dem muligheten til lett å lese koden vår.
Til slutt er dette ikke nødvendigvis et kall til handling for å gå tilbake og refactor alt du har gjort. Nå er det så god tid som noen å begynne å følge standardene. Gode utviklere forbedrer hele tiden, så det er helt akseptabelt å starte nå (selv om det er midt i et prosjekt).
En av de mest nyttige tingene du kan gjøre når du skriver kode er å legge igjen nyttige kommentarer som forklarer nøyaktig hva det er du prøver å gjøre.
Naturligvis kan kommentarer ligge på klassenivå, funksjonsnivå og linjenivå. De er tillatt i PHP, HTML, JavaScript og CSS, så det er egentlig ingen unnskyldning ikke å inkludere dem et sted.
Visst, skrive kommentarer tar litt ekstra tid, men husk at hvis det var lett å lese, ville det ikke bli kalt kode.
Tenk på det på denne måten: Programmører er beryktede for å gå tilbake til sine tidligere prosjekter og anerkjenne hvor ille deres kode er, eller hvordan vi ville gjøre noe annerledes hvis vi jobbet med dette prosjektet nå.
Hvis vi sier det om vår egen kode, hva må andre tenke når de ser vår kode, spesielt hvis de kommer fra en mer erfaren bakgrunn?
Hvis du vil ha mer dyptgående tanker om å kommentere både server-side og klientsidekode, må du se gjennom denne serien.
En annen ting vi utviklere kan gjøre er å forenkle våre funksjoner. Selv om jeg skjønner at dette er noe av et subjektivt område, tror jeg at målet med mindre, mer fokuserte funksjoner gjør koden mer lesbar og til slutt kan hjelpe med testbarhet (hvis du er interessert i å gå den ruten).
For det første er det ikke uvanlig å se funksjoner som overstiger 30, 40 eller 50 linjer. Problemet er at disse funksjonene ofte gjør mer enn én ting.
Dette er problematisk fordi:
Så med det sagt er det noen praktiske tips som vi kan følge for å forbedre kvaliteten på våre funksjoner.
Hvis du finner deg selv det samme om og om igjen blant forskjellige funksjoner, så er det et tilfelle for når du må trekke ut den aktuelle delen av koden og flytte den til egen funksjon slik at den kan bli kalt av alle stedene som det eksisterer for tiden.
Hvis du finner at koden din er komplisert å beskrive med kommentarer eller vanskelig å spore mens du leser gjennom det, kan det være verdt å ta et steg tilbake og refactoring koden til noe litt enklere.
Dette ser annerledes ut i hver situasjon, men strever for lesbarhet over kompleksitet er ofte ganger et bedre mål å streve for enn å bare få noe som fungerer.
Dette er uten tvil det mest subjektive punktet, jeg synes det er verdt å bringe opp, og det er rett og slett at vi bør streve for å holde våre funksjoner små med 20 linjer lang å være en relativt solid lengde for å sikte. Visst, dette kan være litt av en utfordring med at WordPress ofte krever at vi lager store arrayer for å passere som argumenter, men du får ideen: Hold dem små, fokuserte og vedlikeholdbare.
Ja, dette vil resultere i flere funksjoner, men koden blir lettere å lese og vedlikeholde, da hver funksjon har et enkelt bestemt formål. Dette betyr at du kan navngi dem med større klarhet og gi enhetstester rundt dem lettere.
Det er åpenbart at ingen av de ovennevnte er vanskelige regler som må følges - de er bare forslag til hvordan du kan forbedre kvaliteten på koden vi skriver, som vi opprettholder, og at vi bidrar til andres arbeid.
Ovenfor tror jeg at vi skal strebe etter lesbarhet og testbarhet. Å holde disse to målene er forkant av vårt arbeid, og det vil hjelpe til med å kjøre alt annet til sitt rette sted.
Selvfølgelig er dette ikke en komplett liste - det er langt fra det! Så vær så snill å gi opp forslagene dine i kommentarene!
Accentsconagua