For å sikre at WordPress-koden er designet i samme stil overalt og er lett å lese i kjernen, plugins og temaer, anbefales det å følge kodestandardene som er vedtatt av WordPress-utviklere. Disse standardene er veldig like PEAR-standarden, men det er betydelige forskjeller. Jeg anbefaler at du gjør deg kjent med dem og om mulig følger dem når du lager plugins eller temaer.

I tillegg til standarder for å skrive selve PHP-koden, finnes det også standarder for å dokumentere kode – dette er kommentarer til funksjoner og kroker: PHP Documentation Standards (engelsk)

Enkelte og doble anførselstegn

Hvis det ikke er noen variabler i strengen, bruk enkle anførselstegn, ellers doble anførselstegn. Det er ikke nødvendig å unnslippe anførselstegn i en streng, og hvis de er til stede, anbefales det å veksle mellom dem:

Ekko "Link navn"; echo "$linkname";

Den andre linjen i dette eksemplet sletter ikke utdatavariablene, noe som må gjøres av sikkerhetsgrunner. Derfor, for en slik skriving, må variablene slettes på forhånd. Generelt kan et slikt opptak anses som uakseptabelt! Se veiledningsdelen om sikker utgang.

Innrykk

Innrykk skal alltid vise den logiske strukturen til koden. Bruk tabulatorer (Tab-tast) i stedet for mellomrom – dette gir mer fleksibilitet. Mellomrom bør brukes når du trenger å justere noe innenfor en linje.

Regel: tabulatorer skal brukes på begynnelsen av en linje for innrykk, mens mellomrom kan brukes i midten av en linje for justering.

If (betingelse) ( $foo = "somevalue"; $foo2 = "somevalue2"; $foo_bar = "somevalue3"; $foo5 = "somevalue4"; )

Og slik ser koden ut hvis du viser usynlige tabulator- og mellomromstegn:

If (betingelse) ( ---$foo.....= "somevalue"; ---$foo2....= "somevalue2"; ---$foo_bar.= "somevalue3"; ---$foo5 ....= "en eller annen verdi4";

For assosiative matriser må verdiene starte på en ny linje. Det anbefales å sette "siste" komma når du viser array-elementer - dette gjør det mer praktisk å legge til nye elementer...

$my_array = array(---"foo"..=> "somevalue", ---"foo2"..=> "somevalue2", ---"foo3"..=> "somevalue3", -- - "foo34".=> "somevalue3",);

Krøllete seler stil

Krøllete seler må brukes til alle blokker i stilen, som vist nedenfor:

If (betingelse) ( handling1(); handling2(); ) elseif (betingelse2 && betingelse3) ( handling3(); handling4(); ) else ( standardhandling(); )

Hvis det er en lang blokk, bør den brytes ned i to eller flere korte blokker eller funksjoner hvis mulig. Hvis en så lang blokk er nødvendig, legg til en kort kommentar på slutten for å gjøre det klart hva den krøllede bøylen lukker. Denne tilnærmingen er logisk å bruke for en blokk med 35 eller flere linjer.

Enhver kode som ikke er intuitiv bør kommenteres ut.

Bruk alltid krøllete seler, selv om de ikke er nødvendige.

If (betingelse) ( handling0(); ) if (tilstand) ( handling1(); ) elseif (betingelse2) ( handling2a(); handling2b(); ) foreach ($items som $item) ( process_item($item); )

Merk at kravet om å bruke krøllete bukseseler alltid betyr at konstruksjoner i enkeltlinjestil er forbudt.

$var = "farlig""; // rådata som kan eller ikke er escaped $id = some_foo_number(); // data forventet som et tall, men vi er ikke sikre $wpdb->query($wpdb-> prepare( "OPPDATERING $wpdb->posts SET post_title = %s WHERE ID = %d", $var, $id));

%s brukes for strenger og %d for heltall. Vær oppmerksom på at de ikke er "i anførselstegn"! $wpdb->prepare() selv unnslipper strenger og legger til anførselstegn om nødvendig. Fordelen med prepare() er at du ikke trenger å huske å bruke esc_sql() manuelt, og også at spørringsstrengen med plassholdere er mer visuell enn om den brukte variabler pakket inn i esc_sql() .

Databasespørringer

Prøv å ikke skrive direkte spørringer til databasen. Hvis det er en passende funksjon, og det er mange av dem i WP, som kan få de nødvendige dataene, bruk den.

Bruk av funksjoner i stedet for spørringer bidrar til å opprettholde fremtidig kodekompatibilitet. I tillegg fungerer mange funksjoner med cachen, og dette kan øke hastigheten på koden betydelig.

Navn på klasser, funksjoner, filer, konstanter, variabler

Navn på funksjoner, variabler, kroker

Bruk små bokstaver a-z i variabler, kroker og funksjonsnavn og aldri CamelCase . Skill enkeltord med understreker _. Ikke forkort variabelnavn med mindre det er nødvendig; holde koden entydig og selvdokumenterende.

Funksjon some_name($some_variable) ( [...] )

Klassenavn

Du må bruke ord med store_bokstaver atskilt med understrek. Eventuelle forkortelser (akronymer, forkortelser) må være STORE.

Class Walker_Category utvider Walker ( [...] ) klasse WP_HTTP ( [...] )

Konstanter må være STORE BOKSTAVER ord atskilt med understreker:

Define("DOING_AJAX", true);

Filnavn

Må være tydelig og må også bare inneholde små bokstaver, og ord må skilles med bindestrek - .

Mitt-plugin-navn.php

Klassefilnavn

Skal være basert på klassenavnet med prefikset class- , understrekingen i klassenavnet erstattes med en bindestrek, for eksempel blir WP_Error:

Class-wp-error.php

Denne filnavnestandarden er gyldig for alle eksisterende og nye klassefiler. Imidlertid er det unntaksfiler: class.wp-dependencies.php, class.wp-scripts.php, class.wp-styles.php. Disse filene er prefiks med klasse. , et punktum etter ordklassen i stedet for en bindestrek.

Tydelige verdier av variabler i funksjonsparametere

Boolske verdier foretrekkes fremfor strengverdier. De. I stedet for true/false når du kaller funksjoner, er det bedre å bruke en slags streng som forklarer verdien til parameteren.

Dårlig kode:

Funksjon eat($what, $slowly = true) (...) eat("sopp"); spise("sopp", sant); // hva betyr sant? eat("dogfood", falsk); // hva betyr usann, det motsatte av sant?

Siden PHP ikke støtter navngitte argumenter, er flaggverdiene meningsløse og hver gang vi møter et funksjonskall, som i eksemplene ovenfor, må vi se på dokumentasjonen for funksjonen. Koden kan være mer lesbar ved å bruke beskrivende strengverdier i stedet for boolske verdier.

Bra kode:

Funksjon eat($what, $speed = "sakte") ( ... ) eat("sopp"); eat("sopp", "sakte"); eat("dogfood", "raskt");

Når du trenger flere funksjonsparametere, bruk $args-arrayen. Han er enda bedre!

Veldig bra kode:

Funksjon eat($what, $args) ( ... ) eat("nudler", array("speed" => "moderat"));

Interpolering for dynamiske kroknavn

For enkel lesbarhet og gjenkjenning bør kroker med variabler i navnene deres interpoleres (omsluttet av krøllete klammeparenteser ( og )), og bør ikke settes sammen:

Parentesene er nødvendige for at PHP kan analysere datatypene til variablene i den interpolerte strengen korrekt.

// correct do_action("($new_status)_($post->post_type)", $post->ID, $post); // feil do_action($new_status "_". $post->post_type, $post->ID, $post);

Der det er mulig, bør dynamiske verdier i taggnavn også være så korte og presise som mulig. $user_id er mye klarere enn for eksempel $this->id .

Ternær operatør

Ternære operatorer er gode, men de anbefaler at du alltid tester for en sann påstand i stedet for en falsk påstand. Ellers er det rett og slett misvisende på grunn av det doble negative. Unntaket er bruk! empty() fordi noen ganger er det bare vanskelig å skrive det på en annen måte.

Slik sjekker du:

// (hvis betingelsen er sann = sann) ? (da gjør vi dette) : (ellers dette); $music_type = ("jazz" == $musikk) ? "kul" : "bla"; // (hvis verdien ikke er tom - ! tom) ? (da gjør vi dette) : (ellers dette);

Hvordan ikke skrive:

// (hvis betingelsen ikke er oppfylt!= sant) ? (da gjør vi dette) : (ellers dette); $music_type = ("jazz" != $musikk) ? "bla" : "kul";

Mester Yodas betingelser

Når du utfører logiske sammenligninger, sett alltid konstanter eller bokstaver til venstre og en variabel til høyre.

If (true == $the_force) ( $victorious = you_will($be); )

Hvis vi utelater det andre =-tegnet i eksemplet ovenfor (riktignok, dette skjer med selv de mest erfarne av oss), vil vi få en PHP-feil og vi vil umiddelbart se den fordi koden ikke vil fungere. Men hvis konstruksjonen var motsatt - $the_force = true , ville betingelsen alltid være oppfylt og vi ville ikke se noen feil, og vi kunne gå glipp av en så alvorlig feil, som også noen ganger er vanskelig å fange!

Du trenger bare å venne deg til denne "opp-ned"-stavingen.

Dette gjelder også for == , != , === og !== . "Yodas betingelser" for< , > , <= или >= mye vanskeligere å lese og det er bedre å ikke bruke dem her.

Smart kode

Kort sagt, lesbarheten til koden bør være i forgrunnen, det er viktigere enn korthet eller noen ikke åpenbare, men praktiske forkortelser.

Isset($var) || $var = noen_funksjon(); // eller! isset($var) && $var = some_function();

Ja - dette er et kult opptak, det er tydelig at det ble laget av en erfaren programmerer. Men enhver annen utvikler, og ofte til og med forfatteren, for å forstå en slik post må fordype seg litt og bruke ekstra sekunder eller minutter. Dette er ikke en åpenbar eller tydelig oppføring og bør unngås, og det er bedre å skrive det lenger, men tydeligere:

If (! isset($var)) ( $var = some_function(); )

Feilundertrykkelse operatør @

PHP støtter én feilkontrolloperatør: @-tegnet. I tilfelle det går foran et uttrykk i PHP-kode, vil eventuelle feilmeldinger som genereres av det uttrykket bli ignorert.

Mens denne operatoren finnes i kjernen, brukes den ofte fordi man er for lat til å behandle en variabel riktig. Bruken er sterk Ikke anbefalt siden til og med PHP-dokumentasjonen sier:

Oppmerksomhet: I dag undertrykker "@"-operatøren utgangen av meldinger selv om kritiske feil som avbryter skriptet. Dette betyr blant annet at dersom du brukte "@" for å undertrykke feil som oppstår ved kjøring av en funksjon, hvis den ikke er tilgjengelig eller er skrevet feil, vil videre kjøring av skriptet stoppes uten varsel.

En dag bestemte du deg for å lage din egen nettside eller blogg, og for styringssystemet valgte du WordPress... Ettersom tiden gikk ble siden din mer og mer lesbar og da innså du at for enda større popularitet må du legge til litt funksjonalitet til nettstedet eller bare automatiser noe av den handlingen.

Du går til "lageret" av wordpress-plugins og oppdager at plugin-en du trenger ikke er der. Hva å gjøre? Hva burde jeg gjøre? Hvis du i det minste er litt kjent med det grunnleggende om programmering i PHP, layout, så vil det ikke være vanskelig for deg Skriv en plugin for WordPress selv.

La oss nå gå til "kjøkkenet" for å forberede plugin-en vår.

P.s. Hvis du ikke har kunnskap i php og layout... ikke bekymre deg, be noen om å skrive deg den nødvendige funksjonaliteten :)

Før du begynner å skrive en plugin, må du referere til WordPress-dokumentasjonen, som beskriver de grunnleggende prinsippene for å skrive plugins og noen kodeeksempler.

Jeg vil ikke duplisere denne informasjonen, men går rett til å skrive koden.

La oss skrive en enkel plugin som lar deg lagre og vise anmeldelser om nettstedet ditt. Selvfølgelig finnes slike plugins allerede, men dette vil fungere fint som et eksempel.

Det første vi skal gjøre er å komme opp med et unikt navn for plugin-en vår - " AdvUserReviews«.

Deretter vil vi opprette en ny katalog "advuserreviews" i katalogen på nettstedet ditt "/wp-content/plugins/". Og i den vil vi lage en fil "advuserreviews.php". Dette vil være hovedfilen som vil være ansvarlig for generell initialisering. (Det anbefales å bruke UTF-8-koding for filer).

Helt i begynnelsen av filen må du spesifisere grunnleggende informasjon om plugin

Nå, hvis du går til kontrollpanelet, kan du se at systemet har funnet en ny plugin og tilbyr å aktivere den. Men det er for tidlig å gjøre dette ennå.

Vi vil skrive vår nye plugin i OOP-stil og all databehandling vil være plassert i én fil. La oss lage hovedskjelettet til filen.

// Stop direct call if(preg_match("#" . basename(__FILE__) . "#", $_SERVER["PHP_SELF"])) ( die("Du har ikke lov til å ringe denne siden direkte."); ) if (!class_exists("AdvUserReviews")) ( klasse AdvUserReviews ( // Lagring av interne data offentlig $data = array(); // Objektkonstruktør // Initialisering av hovedvariabler funksjon AdvUserReviews() ( ) ) ) global $rprice; $rprice = new AdvUserReviews();

La oss nå legge til følgende kode til objektkonstruktøren:

Funksjon AdvUserReviews() ( global $wpdb; // Deklarer initialiseringskonstanten til plugin-modulen DEFINE("AdvUserReviews", true); // Filnavnet til plugin-en vår $this->plugin_name = plugin_basename(__FILE__); // URL-adresse for vår plugin $ this->plugin_url = trailingslashit(WP_PLUGIN_URL."/".dirname(plugin_basename(__FILE__))) // Tabellen for lagring av anmeldelser // $wpdb-variabelen må erklæres globalt $this->tbl_adv_reviews = $ wpdb->prefiks . "adv_reviews"; // Funksjon som kjøres når plugin er aktivert register_activation_hook($this->plugin_name, array(&$this, "activate")); deaktivert register_deactivation_hook($this->plugin_name, array) (&$this, "deactivate")); );

I objektkonstruktøren bruker vi 3 "kroker" eller "kroker" (hva er de?): register_activation_hook, register_deactivation_hook Og register_uninstall_hook- dette er funksjonene som utføres når plugin er henholdsvis aktivert, deaktivert og slettet.

La oss nå implementere disse funksjonene direkte.

/** * Aktiver plugin */ function activate() ( global $wpdb; require_once(ABSPATH . "wp-admin/upgrade-functions.php"); $table = $this->tbl_adv_reviews; // Bestem mysql-versjonen if ( version_compare(mysql_get_server_info(), "4.1.0", ">=")) ( if (! tomme($wpdb->charset)) $charset_collate = "STANDARD TEGNSETT $wpdb->charset"; if (! empty( $wpdb->collate)) $charset_collate .= "SAMLER $wpdb->kollate"; `ID` INT(10) USIGNERT NULL AUTO_INCREMENT, `review_title` VARCHAR(255) NOT NULL DEFAULT "0", `review_text` TEXT NOT NULL, `review_date` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP, `VAR0)CHARNU_NAME` `review_user_email` VARCHAR(200) NULL, PRIMARY KEY (`ID`))".$charset_collate.";"; // Se etter tabelleksistens hvis ($wpdb->get_var("vis tabeller som "".$table. """ ) != $table) ( dbDelta($sql_table_adv_reviews); ) ) /** * Deaktiver plugin */ function deactivate() ( return true; ) /** * Fjerning av en plugin */ function uninstall() ( global $wpdb; $wpdb->query("DROP TABLE IF EXISTS ($wpdb->prefix)adv_reviews"); )

Variabel $wpdb Ansvarlig for spørsmål til databasen. Funksjon dbDelta analyserer gjeldende tabellstruktur, sammenligner den med ønsket tabellstruktur, og legger enten til eller modifiserer tabellen etter behov.

Følgelig, når plugin er aktivert, opprettes en tabellstruktur for å lagre anmeldelser. Når plugin er deaktivert, skjer ingen handling, men når den slettes, sletter vi tabellen vår. Handlingene kan forstås mer detaljert fra kildekoden.

Den grunnleggende strukturen til den nye plugin-en er klar. Nå må vi begynne å skrive den funksjonelle delen. For å gjøre dette må vi legge til følgende kodelinjer til klassekonstruktøren:

// Hvis vi er i admin. grensesnitt if (is_admin()) ( // Legg til stiler og skript add_action("wp_print_scripts", array(&$this, "admin_load_scripts")); add_action("wp_print_styles", array(&$this, "admin_load_styles")); // Legg til en meny for pluginet add_action("admin_menu", array(&$this, "admin_generate_menu") else ( // Legg til stiler og skript add_action("wp_print_scripts", array(&$this, "site_load_scripts"); ) ; add_action("wp_print_styles", array(&$this, "site_load_styles"));

La oss se på denne delen av koden mer detaljert. La oss starte med administrasjonspanelet.
Funksjon " is_admin» sjekker i hvilken modus vi jobber for øyeblikket - på nettsiden eller i kontrollpanelet.
Deretter brukes flere kroker til funksjoner:

• wp_print_scripts- Legg til de nødvendige javascript-filene
• wp_print_styles- Legg til de nødvendige stilene
• admin_menu- Legge til en ny meny til kontrollpanelet

Hver krok tilsvarer en implementert metode i klassen vår. Der de nødvendige operasjonene utføres.
La oss se på koden for tilkobling av stiler og skript

/** * Laster de nødvendige skriptene for administrasjonssiden * i administrasjonspanelet */ function admin_load_scripts() ( // Register scripts wp_register_script("advReviewsAdminJs", $this->plugin_url . "js/admin-scripts.js") ; wp_register_script( "jquery", $this->plugin_url. "js/jquery-1.4.2.min.js"); de nødvendige stilene for kontrollsiden * i administrasjonspanelet */ function admin_load_styles() ( // Registrer stiler wp_register_style("advReviewsAdminCss", $this->plugin_url . "css/admin-style.css"); // Legg til stiler wp_enqueue_style( "advReviewsAdminCss");

Følgende funksjoner brukes her.

Hver handling avhenger av den beståtte parameteren "handling", henholdsvis "rediger" - redigering av en anmeldelse, "send inn" - lagring av en redigert anmeldelse og "slett" - sletting av en anmeldelse.

Datautveksling med visningssider skjer gjennom objektegenskapen "data". Kildekoden til disse sidene vil bli lagt ut i arkivet med denne modulen på slutten av artikkelen. Jeg vil ikke sette dem inn her, siden emnet allerede er ganske stort.

Det er her vi avslutter med administrasjonspanelet og går videre til å vise og legge til anmeldelser fra brukere.

For å fortelle WordPress når vi skal ringe plugin-en vår, må vi registrere "kortkode", som er det som ble gjort i konstruktøren til klassen vår. Les mer om dette.

Add_shortcode("show_reviews", array (&$this, "site_show_reviews"));

Nå kan du plassere følgende kode på hvilken som helst side på nettstedet, og det vil tvinge funksjonen vi spesifiserte (vedtatt som den andre parameteren) til å bli utført. Nedenfor er kildekoden for denne funksjonen.

/** * Liste over anmeldelser på nettstedet */ public function site_show_reviews($atts, $content=null) ( global $wpdb; if (isset($_POST["action"]) && $_POST["action"] = = " add-review") ( $this->add_user_review(); ) // Velg alle anmeldelser fra databasen $this->data["reviews"] = $wpdb->get_results("SELECT * FROM `" . $ this- >tbl_adv_reviews "`", ARRAY_A; ) privat funksjon add_user_review() ( global $wpdb; $inputData = array("review_title" => strip_tags($_POST["review_title"]), "review_text" => strip_tags($_POST["review_text"]), " review_user_name " => strip_tags($_POST["review_user_name"]), "review_user_email" => strip_tags($_POST["review_user_email"]),); // Legg til en ny anmeldelse til nettstedet $wpdb->insert($this- > tbl_adv_reviews, $inputData);

I prinsippet er det ikke noe komplisert her - en SQL-spørring gjøres for å velge data, men hvis "handling" -parameteren er bestått, blir en ny anmeldelse først lagt til. Men det er verdt å være oppmerksom på utgangsbuffring. Det er nødvendig for å få tak i dataene til den innsatte siden.

Det er alt. Nå kan vi se hva vi har. EN Last ned plugin og kildekoder du kan her.

Dette er selvfølgelig bare et eksempel på å lage en plugin, men den vil også fungere som en enkel gjesteapp hvis du endrer den litt, for eksempel ved å legge til beskyttelse mot roboter og side-for-side-utdata. Lykke til med kodingen :)

Skjema på nettsiden:

Plugin kontrollpanel:

Redigeringsanmeldelse:

Du kan også være interessert i:

Alle nybegynnere webmastere blir redde og satt ut av å jobbe med kode - de er redde for å skade nettstedet sitt ved å legge til HTML eller PHP på det, eller sette det inn på feil sted. Hvis du legger koden på feil sted i WordPress, kan du selvfølgelig ødelegge alt. Imidlertid er dette CMS så godt skreddersydd for nybegynnere at det vil være vanskelig å gjøre feil.

I denne artikkelen skal vi se på hvordan du trygt setter inn HTML- eller PHP-kode i WordPress. Men først, hvorfor dette kan være nyttig.

Hvorfor legge inn kode i WordPress

I løpet av nettstedets levetid kan det hende at webmaster må installere kode på WordPress som må kjøres på sidene. Dette kan være nødvendig av ulike årsaker: for eksempel å installere en trafikkteller, en uvanlig widget eller legge til personlighet til malen.

WordPress tilbyr to måter å installere koden på. La oss se på dem.

Installasjon ved hjelp av tekst-widgeten

For å installere kode på WordPress ved hjelp av en widget, må du gå til menyelementet i "Utseende"-konsollen, og underelementet "Widgets". Blant dem bør du finne "Tekst" og flytte den til ønsket område med musen.

Widgeten åpnes og du kan fylle inn tittelen, samt plassere den nødvendige koden i det aktuelle feltet. Etter å ha klikket på "Lagre"-knappen, vil operasjonen utføres på sidene.

Denne metoden for å installere kode på WordPress er egnet for å utføre operasjoner i HTML, PHP og til og med JavaScript. Denne metoden brukes ofte fordi den er enkel og fungerer bra for nybegynnere.

Installasjon til fil

Å installere kode på WordPress ved hjelp av filredigering anbefales ikke for nybegynnere, men før eller siden må alle mestre det. Denne metoden er praktisk fordi HTML eller PHP kan plasseres i hvilken som helst del, ikke bare widgetområdet, som beskrevet i den første metoden. Ulempen med denne installasjonsmetoden er at den kan være farlig, og hvis det gjøres feil, kan det føre til at siden ikke fungerer. Derfor, før du bruker denne metoden, må du lage en sikkerhetskopi av filene og databasen.

For å installere kode direkte i en fil på WordPress, må du vite hvilket område av nettstedet en bestemt fil er ansvarlig for. Det er umulig å gi nøyaktige anbefalinger her, siden forskjellige filer utfører visse funksjoner i forskjellige maler. Du kan imidlertid lære noe om temafiler. I tillegg til å installere koden i malfilen på WordPress, kan dette også gjøres i filene til selve CMS.

Kodelesbarhet er et veldig sensitivt emne og må vies behørig oppmerksomhet. I denne artikkelen vil du lære 16 teknikker som vil hjelpe deg videre i dette emnet.

1. Kommentarer og dokumentasjon

IDE-er blir stadig mer populære i utviklerverdenen fordi... de gir praktiske verktøy for å kommentere og dokumentere kode.

Her er et eksempel:

Her er et annet eksempel på å kalle din egen metode:

I dette eksemplet er kommentarstilen basert på PHPDoc, og IDE-en jeg bruker er Aptana.

2. Innrykk

Jeg antar at du allerede vet viktigheten av innrykk i koden din. Generelt er det flere stiler for kodeformatering.

Funksjon foo() ( if ($maybe) ( do_it_now(); igjen(); ) else ( abort_mission(); ) finalize(); )

Funksjon foo() ( if ($maybe) ( do_it_now(); igjen(); ) else ( abort_mission(); ) finalize(); )

Funksjon foo() ( if ($maybe) ( do_it_now(); igjen(); ) else ( abort_mission(); ) finalize(); )

Personlig bruker jeg oftest stil #2, men noen ganger bytter jeg til #1. Men dette er selvfølgelig en smakssak. Mest sannsynlig er det ingen "beste" stil som passer absolutt alle. Disse reglene må først og fremst følges av de som jobber i et team eller deltar i å skrive åpen kildekode-prosjekter.

Det er også stiler som kombinerer visse egenskaper. For eksempel PEAR-kodeskrivingsstandardene, der den krøllete klammeparentesen "(" i betingede utsagn forblir på samme linje, men flyttes i funksjoner.

PEAR stil:

Funksjon foo() ( // på en ny linje if ($maybe) ( // på samme linje do_it_now(); igjen(); ) else ( abort_mission(); ) finalize(); )

Det bør også bemerkes at denne stilen bruker 4 mellomrom i stedet for tabulatorer.

Du kan lære mer om de forskjellige stilene.

3. Unngå unødvendige kommentarer

Ja, kommentarkoden er bra; men det er ingen grunn til å overdrive det. Her er et eksempel:

// få landskoden $country_code = get_country_code($_SERVER["REMOTE_ADDR"]); // hvis landet er USA if ($country_code == "US") ( // vis formen echo form_input_state(); )

Hvis arbeidet med koden er åpenbart, bør du mest sannsynlig ikke skrive unødvendige kommentarer.

Hvis du ikke har dem, kan du forkorte dem litt:

// vis skjemaet hvis landet er US $country_code = get_country_code($_SERVER["REMOTE_ADDR"]); if ($country_code == "US") ( echo form_input_state(); )

4. Kodegruppering

Oftest krever noen oppgaver å skrive flere linjer med kode. Derfor er det best å kombinere slike oppgaver i separate blokker atskilt med mellomrom.

Her er et enkelt eksempel:

// få listen over fora $forums = array(); $r = mysql_query("VELG ID, navn, beskrivelse FRA forumene"); while ($d = mysql_fetch_assoc($r)) ( $forums = $d; ) // last inn malen load_template("header"); load_template("forum_list",$fora); load_template("bunntekst");

Hvis du legger til en kommentar før starten av hver blokk, vil dette forbedre lesbarheten til koden din ytterligere.

5. Navneordning

Noen ganger til og med i PHP-språket kan du finne inkonsekvenser i navnefunksjoner. Og her er mange eksempler:

• strpos() vs str_split()
• imagetypes() vs image_type_to_extension()

Det er flere populære stiler:

• camelCase: setter den første bokstaven i stort i hvert nytt ord.
• understreker: Understrek mellom ord: mysql_real_escape_string().

Hvis du blander disse teknikkene, kan du før eller siden havne i en vanskelig situasjon. Hvis du jobber med et prosjekt som bruker en av disse teknikkene, bør du følge etter. Dette kan fortsatt avhenge av programmeringsspråket. For eksempel bruker de fleste Java-utviklere camelCase, mens PHP-utviklere foretrekker understrek.

Men også her var det en hybrid. Noen utviklere bruker understrek i navngivning av klasser og metoder (utenfor klasser), og i andre tilfeller bruker camelCase:

Klasse Foo_Bar ( offentlig funksjon someDummyMethod() ( ) ) funksjon prosedyrefunksjonsnavn() ( )

Nok en gang vil jeg si at det ikke finnes noen beste stil. Du må bare holde deg til noe.

6. TØRR-prinsippet

DRY (Ikke gjenta deg selv) - ikke gjenta deg selv. Også kjent som DIE: Duplication is Evil.

Hovedoppgaven til ethvert system, enten det er en nettapplikasjon eller noe annet, er å automatisere repeterende oppgaver. Dette prinsippet bør følges alltid og overalt, spesielt hvis du er en utvikler. Den samme kodebiten bør ikke gjentas om og om igjen.

For eksempel består de fleste nettapplikasjoner av én eller flere sider. Det er klart at disse sidene vil inneholde de samme elementene. Topptekst og bunntekst er de mest slående eksemplene. Du vil bli overrasket over hvor mange som fortsatt dupliserer disse elementene på hver side.

$this->load->view("inkluderer/header"); $this->load->view($main_content); $this->load->view("inkluderer/bunntekst");

7. Unngå dyp hekking

Kodes lesbarhet reduseres kraftig hvis du har dyp hekking.

Funksjon do_stuff() ( // ... if (er_skrivbar($mappe)) ( if ($fp = fopen($filbane,"w")) ( if ($stuff = get_some_stuff()) ( if (fwrite($ fp,$stuff)) ( // ... ) else ( return false; ) ) else ( return false; ) ) else ( return false; ) ) else ( return false; ) )

For å rette opp situasjonen, bør du revurdere hvordan koden din fungerer og optimalisere den:

Funksjonen do_stuff() ( // ... if (!er_skrivbar($mappe)) (retur falsk; ) if (!$fp = fopen($filbane,"w")) (retur falsk; ) if (!$ting = get_some_stuff()) ( return usann; ) if (fwrite($fp,$stuff)) ( // ... ) else ( return false; ) )

8. Linjelengdegrense

Alle vet at leseprosessen blir mye morsommere når teksten er delt inn i spalter. Dette er hovedgrunnen til at avisene våre ser slik ut:

En lignende teknikk kan brukes på koden vår:

// dårlig $my_email->set_from(" [e-postbeskyttet]")->add_to(" [e-postbeskyttet]")->set_subject("Methods Chained")->set_body("Noen lang melding")->send(); // bra $my_email ->set_from(" [e-postbeskyttet]") ->add_to(" [e-postbeskyttet]") ->set_subject("Methods Chained") ->set_body("Noen lang melding") ->send(); // bad $query = "VELG id, brukernavn, fornavn, etternavn, status FRA brukere VENSTRE BLI MED I user_posts BRUKER (users.id, user_posts.user_id) WHERE post_id = "123""; // dårlig $query = "VELG id, brukernavn, fornavn, etternavn, status FRA brukere VENSTRE BLI MED I user_posts USING(users.id, user_posts.user_id) HVOR post_id = "123"";

De fleste utviklere holder seg til grensen på 80 og 120 tegn.

9. Organisere filer og mapper

Teknisk sett kan du legge all koden til applikasjonen din i én fil :) Men hva vil du gjøre når du trenger å endre eller legge til noe.

Jeg husker mine første prosjekter der jeg la ved filer. Imidlertid var organisasjonen min veldig dårlig. Jeg opprettet en "inc"-mappe der jeg plasserte flere filer: db.php og functions.php. I løpet av prosessen med å skrive søknaden ble denne mappen større og større og til slutt var det vanskelig å finne ut hva som lå hvor.

For å løse dette problemet er det bedre å bruke forskjellige typer rammer eller i det minste følge strukturen deres. Slik ser prosjektet ut på CodeIgniter:

10. Variabelnavn

Generelt bør variabelnavn være fullstendig meningsfulle - dette er ideelt. Et unntak kan gjøres for midlertidige variabler.

La oss se på noen eksempler:

// $i for for loops ($i = 0; $i< 100; $i++) { // $j для вложенных циклов for ($j = 0; $j < 100; $j++) { } } // $ret для возвращаемых переменных function foo() { $ret["bar"] = get_bar(); $ret["stuff"] = get_stuff(); return $ret; } // $k и $v для foreach foreach ($some_array as $k =>$v) ( ) // $q, $r og $d for mysql $q = "VELG * FRA tabell"; $r = mysql_query($q); while ($d = mysql_fetch_assocr($r)) ( ) // $fp for arbeid med filer $fp = fopen("file.txt","w");

11 - Skriv nøkkelord i SQL med store bokstaver

De fleste webapplikasjoner samhandler med databaser. Hvis du skriver SQL-spørringer selv, må du også formatere dem deretter... Det er ikke noe komplisert her. Bare skriv søkeordene dine med store bokstaver.

12. Skill kode og data

Dette er et annet prinsipp som vil hjelpe deg å skrive mer forståelige programmer. Det innebærer å forberede data på ett sted (for eksempel modeller), og samhandle med dem på et annet.

Da PHP først begynte å utvikle seg, var det mer som et malsystem. Prosjekter på dette språket inneholdt blandet HTML- og PHP-kode. Ting har endret seg nå, og alle bør ta søknadsskrivingen til neste nivå.

Du kan utvikle en spesiell stil for deg selv, eller du kan bruke de mest populære midlene i dag.

Populære PHP-rammer:

Malsystemer:

Populært CMS

13. Spesiell syntaks for maler

Hvis du ikke vil bruke et malsystem, må du mest sannsynlig utvikle din egen stil for å bygge inn PHP-kode i HTML.

Og her er et eksempel:

Mitt oppslagstavle

Denne teknikken lar deg unngå unødvendige parenteser. Dessuten passer slik kode godt inn i HTML-konteksten.

14. Prosedyremessige og objektorienterte tilnærminger

Objektorientert programmering vil hjelpe deg med å holde deg til en mer eller mindre klar struktur, men det betyr ikke at du bør avvike fra prosedyreprinsippene for å skrive søknader.

Objekter er flotte for å representere data. Eksempel:

Klassebruker ( public $username; public $first_name; public $last_name; public $email; public function __construct() ( // ... ) public function create() ( // ... ) public function save() ( / / ... ) offentlig funksjon delete() ( // ... ) )

Prosedyremetoder har sine egne spesifikke fordeler.

Funksjon capitalize($string) ( $ret = strtoupper($string); $ret .= strtolower(substr($string,1)); return $ret; )

15. Les åpen kildekode

Vanligvis er Open Source-prosjekter skrevet av et stort antall utviklere. Fra dette synspunktet kan det å studere den skrevne koden i lignende prosjekter hjelpe deg med å få erfaring. Så ikke kast bort tiden din på dette.

16. Refaktorering

Refaktorering er å endre kode uten å miste funksjonalitet. Den kan også brukes til å forbedre lesbarheten. Det er ikke plass til å fikse feil eller legge til funksjonalitet. Du endrer bare strukturen på koden din litt.

Jeg håper du fant denne artikkelen nyttig! Har jeg gått glipp av noe? Del opplevelsen din!

Jeg tør å anta at det har vært tider i livet ditt da du ønsket å legge til (korrigere) noe til temaet på WP-siden din, eller til funksjonaliteten til en eller annen plugin. Dessuten inkluderte ikke utviklerne denne funksjonen i standardkontroller. Og sjelen din gjenkjenner ingen restriksjoner og krever fancy fly :) Som du forstår, er det en vei ut av enhver situasjon, i dette tilfellet må vi korrigere koden til plugin, tema...

Den største vanskeligheten med å redigere kode er at endringene du gjør, dessverre ikke lagres lenge, og vil mest sannsynlig bli kansellert under neste oppdatering. Hvis løsningen du ser er å unngå oppdateringer, våger jeg å fraråde deg denne farlige uverdige beslutningen, siden oppdateringer inneholder viktige endringer i forhold til sikkerhet og feilrettinger, og ofte også legger til nye funksjoner.

Som et resultat er det å foretrekke å bruke metoder som vil stå opp i vår dynamisk skiftende verden og samtidig spare din dyrebare tid.

Forsiktig!

På Internett kan du ofte finne råd som foreslår å gjøre endringer i filen funksjoner.php- hvis det er noen mulighet til å klare seg uten dette, er det bedre å ikke røre denne filen. I metodene nedenfor vil du se en måte å implementere dette på. Og i alle fall må du lage et undertema og ikke berøre foreldrene.

Når du legger til prefikser til en funksjon, bruk alltid tilpasset kode i skjemaet: _prefiks(til navnet på funksjonen som endres). Denne handlingen vil beskytte deg mot konflikter med andre funksjoner i temaet eller plugin-modulen.

Så, hvordan legger du til kode på et WP-nettsted?

1) Egendefinert plugin

På denne måten kan du sette inn kodebiter, og de vil ikke bli slettet under oppdateringen, og du kan også redigere, aktivere dem i fremtiden, eller omvendt – deaktivere dem etter behov.

Dette er enkelt å gjøre: først må du opprette en katalog for plugin-en din, og gi den et navn, for eksempel moy-plugin (bruk bare bindestreker, ikke underskråstreker)

Deretter lager vi hovedpluginfilen. Som du forstår, bør den inneholde et navn, beskrivelse og grunnleggende informasjon, samt kode som vil bidra til å sikre plugin-en mot inntrengere. Og vi kaller denne filen, la oss si moy-plugin.php. .php-utvidelsen vil fortelle WP hvilket språk filen ble opprettet på.

Du kan opprette en fil ved å bruke metoden beskrevet ovenfor i et hvilket som helst tekstredigeringsprogram, for eksempel NotePad, som allerede er nøye installert i Windows-operativsystemet (TextEdit på Mac). Det er bedre å ikke bruke Microsoft Word-editoren, siden den formaterer teksten, og vi trenger den absolutt ikke i denne situasjonen.

Så her er koden å legge til:

Og under denne koden, gjør endringene dine slik din kreative sjel krever. Det er ikke nødvendig å legge til avsluttende PHP-tagger på slutten. I dette tilfellet vil navnet, beskrivelsen og URL-en vises i administrasjonspanelet ditt. Og selvfølgelig kan du erstatte "ClubWP"-informasjonen med din egen informasjon

Etter det gjenstår det bare å pakke det du har opprettet i et zip-arkiv og sende det til nettstedets ftp. I fremtiden kan du på denne måten gjøre endringer i plugin-en din.

På denne enkle måten vil du lage en enkel plugin for dine behov.

2) Kodebitplugin

Hvis metoden beskrevet ovenfor er vanskelig for deg, eller du er en veldig praktisk person og er vant til å få resultater raskere, ble kodebiter laget spesielt for deg. Akkurat som funksjonen beskrevet ovenfor, legger plugin til koden din med muligheten til å redigere den ytterligere uten å bruke temaet ditt.

Etter at du har installert pluginet, vil et nytt "Snippets"-vindu vises i administrasjonspanelet, der du kan legge til nye snippets. For hvilken du kan angi en kode og informasjon om formålet.

Dermed har du muligheten til å aktivere eller deaktivere tilpasset kode i form av plugins. Veldig praktisk og praktisk, fordi... Noen ganger kan det være konflikter med temaer og plugins, og du kan enkelt forstå dette og deaktivere den genererte koden.

3) Redigeringsfunksjoner.php av et undertema

Hvis bruk av plugins ikke passer for deg, og du må gjøre endringer direkte i temaet på nettstedet ditt, er denne metoden for deg. La meg minne deg på at du bare kan gjøre dette med barnetemaer.

For å bruke denne metoden tilbyr jeg malen min funksjoner.php barn tema. Pakk ut og rediger filen style.css(malnavn og import-URL)

P.S. Prøv å gjøre alt du kan for å forenkle livet ditt i fremtiden, inkludert din harde andel av å eliminere feil og redigere tilpasset kode etter hvert som behovet oppstår.