Share
To ganger i måneden besøker vi noen av våre leseres favorittinnlegg fra hele Nettuts historie+.
Kode lesbarhet er et universelt emne i verden av dataprogrammering. Det er en av de første tingene vi lærer som utviklere. Denne artikkelen vil detaljere de femten viktigste beste praksisene når du skriver lesbar kode.
IDEs (Integrated Development Environment) har kommet langt i de siste årene. Dette gjorde at kommentaren din var mer nyttig enn noensinne. Etter visse standarder i kommentarene dine kan IDEs og andre verktøy bruke dem på forskjellige måter.
Vurder dette eksempelet:
Kommentarene jeg la til ved funksjonen definisjonen kan forhåndsvises når jeg bruker den funksjonen, selv fra andre filer.
Her er et annet eksempel hvor jeg ringer en funksjon fra et tredjepartsbibliotek:
I disse spesielle eksemplene er typen kommentator (eller dokumentasjon) som er brukt, basert på PHPDoc, og IDE er Aptana.
Jeg antar at du allerede vet at du bør legge inn koden din. Det er imidlertid også verdt å merke seg at det er en god ide å holde innrykksstilen din konsistent.
Det er mer enn én måte å indheve kode på.
funksjon foo () hvis ($ kanskje) do_it_now (); en gang til(); ellers abort_mission (); ferdigstille ();
funksjon foo () hvis ($ kanskje) do_it_now (); en gang til(); ellers abort_mission (); ferdigstille ();
funksjon foo () hvis ($ kanskje) do_it_now (); en gang til(); ellers abort_mission (); ferdigstille ();
Jeg pleide å kode i stil # 2, men nylig byttet til # 1. Men det er bare et spørsmål om preferanse. Det er ingen "best" stil som alle skal følge. Egentlig er den beste stilen en konsistent stil. Hvis du er en del av et lag eller hvis du bidrar med koden til et prosjekt, bør du følge den eksisterende stilen som brukes i prosjektet.
Innrykksstilene er ikke alltid helt forskjellige fra hverandre. Noen ganger blander de forskjellige regler. For eksempel, i PEAR-kodestandarder, åpningsbraketten "" går på samme linje som kontrollstrukturer, men de går til neste linje etter funkjonsdefinisjoner.
PEAR-stil:
funksjon foo () // plasseres på neste linje hvis ($ kanskje) // plasseres på samme linje do_it_now (); en gang til(); ellers abort_mission (); ferdigstille ();
Vær også oppmerksom på at de bruker fire mellomrom i stedet for faner for innrykk.
Her er en Wikipedia-artikkel med eksempler på forskjellige innrykksstiler.
Kommenterer koden din er fantastisk; Det kan imidlertid være overdone eller bare være overflødig. Ta dette eksempelet:
// få landskoden $ country_code = get_country_code ($ _ SERVER ['REMOTE_ADDR']); // hvis landskoden er US hvis ($ country_code == 'US') // viser skjemainngangen for statens ekkoform_input_state ();
Når teksten er så åpenbar, er det egentlig ikke produktiv å gjenta det innen kommentarer.
Hvis du må kommentere den koden, kan du bare kombinere den med en enkelt linje i stedet:
// visningstilstandsvalg for amerikanske brukere $ country_code = get_country_code ($ _ SERVER ['REMOTE_ADDR']); hvis ($ country_code == 'US') echo form_input_state ();
Oftere enn ikke, krever enkelte oppgaver noen få linjer med kode. Det er en god ide å beholde disse oppgavene i separate blokker med kode, med noen mellomrom mellom dem.
Her er et forenklet eksempel:
Accentsconagua
// få liste over fora $ forums = array (); $ r = mysql_query ("VELG ID, navn, beskrivelse FRA forumer"); mens ($ d = mysql_fetch_assoc ($ r)) $ forums [] = $ d; // last maler last_template ('header'); load_template ( 'forum_list', $ fora); load_template ( 'bunntekst'); Å legge til en kommentar i begynnelsen av hver blokk av kode legger også vekt på den visuelle separasjonen.
PHP selv er noen ganger skyldig i ikke å følge konsekvent navneordninger:
Først av alt bør navnene ha ordgrenser. Det er to populære alternativer:
Å ha forskjellige alternativer skaper en situasjon som ligner på innrykksstiler, som jeg tidligere nevnte. Hvis et eksisterende prosjekt følger en bestemt konvensjon, bør du gå med det. Enkelte språkplattformer har også en tendens til å bruke et bestemt navngivningssystem. For eksempel, i Java, bruker de fleste koden kamelCase-navn, mens i PHP, understreker de fleste bruksområder.
Disse kan også blandes. Noen utviklere foretrekker å bruke understreker for prosessfunksjoner og klassenavn, men bruk camelCase for klassemetodenavn:
klasse Foo_Bar offentlig funksjon someDummyMethod () funksjon procedural_function_name ()
Så igjen er det ingen åpenbar "best" stil. Bare å være konsekvent.
DRY står for Gjenta ikke selv. Også kjent som DIE: Duplisering er ond.
Prinsippet sier:
"Hvert stykke kunnskap må ha en enkelt, entydig, autoritativ representasjon i et system."
Hensikten med de fleste applikasjoner (eller datamaskiner generelt) er å automatisere repeterende oppgaver. Dette prinsippet bør opprettholdes i alle koden, til og med webapplikasjoner. Det samme koden bør ikke gjentas igjen og igjen.
For eksempel består de fleste webapplikasjoner av mange sider. Det er høyst sannsynlig at disse sidene vil inneholde vanlige elementer. Headers og footers er vanligvis best kandidater til dette. Det er ikke en god ide å holde kopi lime inn disse overskriftene og bunntekstene på hver side. Her er Jeffrey Way forklarer hvordan man lager maler i CodeIgniter.
$ Dette-> last> visning ( 'omfatter / header'); $ Dette-> last> view ($ main_content); $ Dette-> last> view ( 'includes / bunntekst');
For mange nivåer av nesting kan gjøre koden vanskeligere å lese og følge.
funksjon do_stuff () //? hvis (is_writable ($ mappe)) if ($ fp = fopen ($ file_path, 'w')) hvis ($ stuff = get_some_stuff ()) hvis (skriv ($ fp, $ stuff)) //? ellers return false; ellers return false; ellers return false; ellers return false;
For lesbarhets skyld er det vanligvis mulig å gjøre endringer i koden din for å redusere nestnivået:
funksjon do_stuff () //? hvis (! er_writable ($ mappe)) return false; hvis (! $ fp = fopen ($ file_path, 'w')) return false; hvis (! $ stuff = get_some_stuff ()) return false; hvis (skriv ut ($ fp, $ stuff)) //? ellers return false;
Øynene våre er mer komfortable når du leser høye og smale kolonner med tekst. Dette er nettopp grunnen til at avisartikler ser slik ut:
Det er en god praksis å unngå å skrive horisontalt lange kodelinjer.
// dårlig $ my_email-> set_from ('[email protected] ') -> add_to ('[email protected]') -> set_subject ('Methods Chained') -> set_body ('Noen lange meldinger') -> sende(); // god $ my_email -> set_from ('[email protected] ') -> add_to ('[email protected]') -> set_subject ('Methods Chained') -> set_body ('Noen lange meldinger') -> sende(); // dårlig $ query = "VELG ID, brukernavn, fornavn, etternavn, status FRA brukere LEFT JOIN user_posts USING (users.id, user_posts.user_id) WHERE post_id = '123'"; // good $ query = "VELG ID, brukernavn, fornavn, etternavn, status FRA brukere LEFT JOIN user_posts USING (users.id, user_posts.user_id) WHERE post_id = '123'"; Også, hvis noen har tenkt å lese koden fra et terminalvindu, for eksempel Vim-brukere, er det en god idé å begrense linjelengden til rundt 80 tegn.
Teknisk sett kan du skrive en hel søknadskode i en enkelt fil. Men det ville vise seg å være et mareritt å lese og vedlikeholde.
Under mine første programmeringsprosjekter kjente jeg om ideen om å lage "inkludere filer". Imidlertid var jeg ikke engang eksternt organisert. Jeg opprettet en "inc" -mappe med to filer i den: db.php og functions.php. Etter hvert som applikasjonene vokste, ble funksjonsfilen også stor og umulig.
En av de beste tilnærmingene er å enten bruke et rammeverk eller etterligne mappestrukturen. Her ser CodeIgniter ut:
Normalt skal variablene være beskrivende og inneholde ett eller flere ord. Men dette gjelder ikke nødvendigvis for midlertidige variabler. De kan være så korte som en enkelt karakter.
Det er en god praksis å bruke konsekvente navn for dine midlertidige variabler som har samme type rolle. Her er noen eksempler som jeg pleier å bruke i koden min:
// $ i for loop-tellere for ($ i = 0; $ i < 100; $i++) // $j for the nested loop counters for ($j = 0; $j < 100; $j++) // $ret for return variables function foo() $ret['bar'] = get_bar(); $ret['stuff'] = get_stuff(); return $ret; // $k and $v in foreach foreach ($some_array as $k => $ v) // $ q, $ r og $ d for mysql $ q = "SELECT * FROM table"; $ r = mysql_query ($ q); mens ($ d = mysql_fetch_assocr ($ r)) // $ fp for filpekere $ fp = fopen ('file.txt', 'w'); Database-interaksjon er en stor del av de fleste webapplikasjoner. Hvis du skriver rå SQL-spørringer, er det en god ide å holde dem lesbare også.
Selv om SQL-spesielle ord og funksjonsnavn er sakfølsomme, er det vanlig å kapitalisere dem for å skille dem fra tabell- og kolonnens navn.
VELG ID, brukernavn FRA bruker; Oppdatere bruker SET last_login = NÅ () HVOR id = '123' VELG ID, brukernavn FRA bruker du VENSTRE GÅ TIL bruker_address ua PÅ (u.id = ua.user_id) HVOR ua.state = 'NY' GRUPPE AV u.id BESTILL BY u.brukernavn LIMIT 0,20
Dette er et annet prinsipp som gjelder for nesten alle programmeringsspråk i alle miljøer. I tilfelle av webutvikling, betyr "dataene" vanligvis HTML-utgang.
Når PHP ble først utgitt for mange år siden, ble det først og fremst sett på som en malmotor. Det var vanlig å ha store HTML-filer med noen få linjer med PHP-kode i mellom. Men ting har endret seg gjennom årene, og nettsteder ble mer og mer dynamiske og funksjonelle. Koden er nå en stor del av webapplikasjoner, og det er ikke lenger en god praksis å kombinere den med HTML.
Du kan enten bruke prinsippet til søknaden din selv, eller du kan bruke et tredjepartsverktøy (malmotorer, rammebetingelser eller CMS) og følge deres konvensjoner.
Populære PHP Rammer:
Populære malmotorer:
Populære Content Management Systems
Du kan velge å ikke bruke en fancy malmotor, og i stedet gå med vanlig inline PHP i malfiler. Dette bringer ikke nødvendigvis "Separasjon av kode og data", så lenge inline-koden er direkte relatert til utgangen, og kan leses. I dette tilfellet bør du vurdere å bruke alternativ syntaks for kontrollstrukturer.
Her er et eksempel:
Hallo, brukernavn; ?>
|Mitt Meldingstavle
tittel; ?>
Forum som $ forum):?>id, $ forum-> tittel)?> (Threads-> count (); ?> tråder)
beskrivelse; ?>
Dette gjør at du kan unngå mange krøllete braces. Koden ser også ut og føles som den måten HTML er strukturert og innrykket på.
Objektorientert programmering kan hjelpe deg med å lage godt strukturert kode. Men det betyr ikke at du må overgi prosedyreprogrammering helt. Egentlig å lage en blanding av begge stiler kan være bra.
Objekter bør brukes til å representere data, vanligvis bosatt i en database.
klassen bruker offentlig $ brukernavn; offentlig $ first_name; offentlig $ last_name; offentlig $ e-post; offentlig funksjon __construct () //? offentlig funksjon lage () //? offentlig funksjon lagre () //? offentlig funksjon slette () //?
Prosedyrefunksjoner kan brukes til spesifikke oppgaver som kan utføres uavhengig.
funksjonen kapitaliser ($ string) $ ret = strtoupper ($ string [0]); $ ret. = strtolower (substr ($ streng, 1)); returner $ ret;
Open Source-prosjekter er bygget med input fra mange utviklere. Disse prosjektene må opprettholde et høyt nivå av kodelesbarhet slik at teamet kan jobbe sammen så effektivt som mulig. Derfor er det en god ide å bla gjennom kildekoden til disse prosjektene for å observere hva disse utviklerne gjør.
Når du "refactor", endrer du koden uten å endre funksjonaliteten. Du kan tenke på det som en "rydde opp" for å forbedre lesbarheten og kvaliteten.
Dette inkluderer ikke feilrettinger eller tillegg av ny funksjonalitet. Du kan gjenkjenne kode som du har skrevet dagen før, mens den fortsatt er frisk i hodet ditt, slik at den er mer lesbar og gjenbrukbar når du potensielt kan se på den to måneder fra nå. Som mottoet sier: "Refactor tidlig, refactor ofte."
Du kan bruke noen av de "beste metodene" for kode lesbarhet under refactoring prosessen.
Jeg håper du likte denne artikkelen! Noen som jeg savnet? Gi meg beskjed via kommentarene. Og hvis du vil forbedre kodingen, er det mange skript og apper tilgjengelig for å hjelpe deg på Envato Market. Se hva som er mest populært denne uken.
