För att säkerställa att WordPress-koden är designad i samma stil överallt och är lätt att läsa i kärnan, plugins och teman, rekommenderas att följa de kodningsstandarder som antagits av WordPress-utvecklare. Dessa standarder är mycket lika PEAR-standarden, men det finns betydande skillnader. Jag rekommenderar att du bekantar dig med dem och, om möjligt, följer dem när du skapar plugins eller teman.

Förutom standarder för att skriva PHP-kod i sig, finns det även standarder för att dokumentera kod - det här är kommentarer om funktioner och krokar: PHP Documentation Standards (engelska)

Enkla och dubbla citattecken

Om det inte finns några variabler i strängen, använd enkla citattecken, annars dubbla citattecken. Det finns inget behov av att undkomma citattecken i en sträng, och om de finns, rekommenderas att alternera dem:

Echo "Länknamn"; echo "$länknamn";

Den andra raden i detta exempel rensar inte utdatavariablerna, vilket måste göras av säkerhetsskäl. Därför, för en sådan skrivning, måste variablerna rensas i förväg. Generellt sett kan en sådan inspelning anses oacceptabel! Se handledningsavsnittet om säker utdata.

Fördjupningar

Indrag ska alltid visa kodens logiska struktur. Använd tabbar (Tab-tangenten) snarare än mellanslag - detta ger mer flexibilitet. Mellanslag bör användas när du behöver justera något inom en linje.

Regel: tabbar ska användas i början av en rad för indrag, medan mellanslag kan användas i mitten av en linje för justering.

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

Och så här ser koden ut om du visar osynliga tabb- och mellanslagstecken:

If (villkor) ( ---$foo.....= "somevalue"; ---$foo2....= "somevalue2"; ---$foo_bar.= "somevalue3"; ---$foo5 ....= "något värde4"; )

För associativa arrayer måste värden börja på en ny rad. Det rekommenderas att sätta det "sista" kommatecken när du listar arrayelement - detta gör det bekvämare att lägga till nya element...

$my_array = array(---"foo"..=> "något värde", ---"foo2"..=> "något värde2", ---"foo3"..=> "något värde3", -- - "foo34".=> "något värde3",);

Lockigt hängslen stil

Lockiga hängslen måste användas för alla block i stilen, som visas nedan:

If (villkor) ( action1(); action2(); ) elseif (villkor2 && condition3) ( action3(); action4(); ) else ( defaultaction(); )

Om det finns ett långt block bör det delas upp i två eller flera korta block eller funktioner om möjligt. Om ett så långt block är nödvändigt, lägg till en kort kommentar i slutet för att göra det tydligt exakt vad den lockiga hängslen stänger. Detta tillvägagångssätt är logiskt att använda för ett block med 35 eller fler rader.

All kod som inte är intuitiv bör kommenteras bort.

Använd alltid lockiga hängslen, även om de inte behövs.

If (villkor) ( action0(); ) if (villkor) ( action1(); ) elseif (villkor2) ( action2a(); action2b(); ) foreach ($items som $item) ( process_item($item); )

Observera att kravet på att använda lockiga hängslen alltid innebär att konstruktioner av en linje är förbjudna.

$var = "farligt""; // rådata som kan eller inte kan escapes $id = some_foo_number(); // data förväntas som ett tal, men vi är inte säkra $wpdb->query($wpdb-> prepare( "UPPDATERA $wpdb->posts SET post_title = %s WHERE ID = %d", $var, $id));

%s används för strängar och %d för heltal. Observera att de inte står "inom citattecken"! $wpdb->prepare() själv undkommer strängar och lägger till citattecken om det behövs. Fördelen med prepare() är att du inte behöver komma ihåg att manuellt använda esc_sql() , och även att frågesträngen med platshållare är mer visuell än om den använde variabler inslagna i esc_sql() .

Databasfrågor

Försök att inte skriva direkta frågor till databasen. Om det finns en lämplig funktion, och det finns många av dem i WP, som kan få nödvändig data, använd den.

Att använda funktioner istället för frågor hjälper till att upprätthålla framtida kodkompatibilitet. Dessutom fungerar många funktioner med cachen, och detta kan påskynda koden avsevärt.

Namn på klasser, funktioner, filer, konstanter, variabler

Namn på funktioner, variabler, krokar

Använd små bokstäver a-z i variabler, krokar och funktionsnamn och aldrig CamelCase . Separera enskilda ord med understreck _. Förkorta inte variabelnamn om det inte är nödvändigt; hålla koden entydig och självdokumenterande.

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

Klassnamn

Du måste använda ord med versaler avgränsade med understreck. Eventuella förkortningar (akronymer, förkortningar) måste vara KAPITAL.

Klass Walker_Category utökar Walker ( [...] ) klass WP_HTTP ( [...] )

Konstanter måste vara VERSALER ord avgränsade med understreck:

Define("DOING_AJAX", true);

Filnamn

Måste vara tydligt och måste även innehålla endast små bokstäver och ord måste separeras med bindestreck - .

Mitt-plugin-namn.php

Klassfilnamn

Bör baseras på klassnamnet med prefixet class- , understrecket i klassnamnet ersätts med ett bindestreck, till exempel blir WP_Error:

Class-wp-error.php

Denna filnamnsstandard är giltig för alla befintliga och nya klassfiler. Det finns dock undantagsfiler: class.wp-dependencies.php, class.wp-scripts.php, class.wp-styles.php. Dessa filer har prefixet klass. , en punkt efter ordklassen istället för ett bindestreck.

Rensa värden för variabler i funktionsparametrar

Booleska värden föredras framför strängvärden. De där. Istället för sant/falskt när du anropar funktioner är det bättre att använda någon form av sträng som förklarar parameterns värde.

Dålig kod:

Funktion eat($what, $slowly = true) (...) eat("svamp"); eat("svamp", sant); // vad betyder sant? eat("dogfood", false); // vad betyder falskt, motsatsen till sant?

Eftersom PHP inte stöder namngivna argument är flaggvärdena meningslösa och varje gång vi stöter på ett funktionsanrop, som i exemplen ovan, måste vi titta på dokumentationen för funktionen. Koden kan vara mer läsbar genom att använda beskrivande strängvärden istället för booleska värden.

Bra kod:

Funktion eat($what, $speed = "långsamt") ( ... ) eat("svamp"); eat("svamp", "långsamt"); eat("dogfood", "snabbt");

När du behöver fler funktionsparametrar, använd $args-arrayen. Han är ännu bättre!

Mycket bra kod:

Funktion eat($what, $args) ( ... ) eat("nudlar", array("hastighet" => "måttlig"));

Interpolation för dynamiska kroknamn

För att underlätta läsbarhet och upptäckt bör krokar med variabler i deras namn interpoleras (omslutna av krulliga klammerparenteser ( och )) och bör inte sammanfogas:

Parenteserna behövs så att PHP korrekt kan analysera datatyperna för variablerna i den interpolerade strängen.

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

Om möjligt bör dynamiska värden i taggnamn också vara så korta och exakta som möjligt. $user_id är mycket tydligare än till exempel $this->id .

Ternär operatör

Ternära operatorer är bra, men de rekommenderar att du alltid testar för ett sant påstående snarare än ett falskt påstående. Annars är det helt enkelt missvisande på grund av det dubbla negativa. Undantaget är användning! empty() för ibland är det bara svårt att skriva det på något annat sätt.

Så här kontrollerar du:

// (om villkoret är sant = sant) ? (då gör vi så här) : (annars detta); $music_type = ("jazz" == $musik) ? "cool" : "bla"; // (om värdet inte är tomt - ! tomt) ? (då gör vi så här) : (annars detta);

Hur man inte skriver:

// (om villkoret inte är uppfyllt!= sant) ? (då gör vi så här) : (annars detta); $music_type = ("jazz" != $musik) ? "bla" : "cool";

Mästare Yodas villkor

När du utför logiska jämförelser, sätt alltid konstanter eller bokstaver till vänster och en variabel till höger.

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

Om vi ​​utelämnar det andra =-tecknet i exemplet ovan (det här händer visserligen även de mest erfarna av oss), kommer vi att få ett PHP-fel och vi kommer omedelbart att se det eftersom koden inte kommer att fungera. Men om konstruktionen var den motsatta - $the_force = true , så skulle villkoret alltid vara uppfyllt och vi skulle inte se något fel, och vi kunde missa en så allvarlig bugg, som också ibland är svår att fånga!

Du behöver bara vänja dig vid denna "upp och ner" stavning.

Detta gäller även för == , != , === och !== . "Yodas villkor" för< , > , <= или >= mycket svårare att läsa och det är bättre att inte använda dem här.

Smart kod

Kort sagt, läsbarheten av koden bör vara i förgrunden, det är viktigare än korthet eller några otydliga, men bekväma förkortningar.

Isset($var) || $var = någon_funktion(); // eller! isset($var) && $var = some_function();

Ja - det här är en cool inspelning, det är tydligt att den gjordes av en erfaren programmerare. Men alla andra utvecklare, och ofta till och med författaren, för att förstå en sådan post måste fördjupa sig lite och spendera extra sekunder eller minuter. Detta är inte en självklar eller tydlig post och bör undvikas, och det är bättre att skriva det längre, men tydligare:

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

Felundertryckande operatör @

PHP stöder en felkontrolloperatör: @-tecknet. Om det föregår något uttryck i PHP-kod, kommer alla felmeddelanden som genereras av det uttrycket att ignoreras.

Även om den här operatorn finns i kärnan, används den ofta eftersom man är för lat för att bearbeta en variabel ordentligt. Dess användning är stark Rekommenderas inte eftersom till och med PHP-dokumentationen säger:

Observera: Idag undertrycker "@"-operatören utmatningen av meddelanden även om kritiska fel som avbryter skriptet. Det betyder bland annat att om du använde "@" för att undertrycka fel som uppstår när en funktion körs, om den inte är tillgänglig eller är felaktigt skriven, kommer vidare exekvering av skriptet att stoppas utan någon avisering.

En dag bestämde du dig för att skapa din egen hemsida eller blogg, och för ledningssystemet valde du WordPress... Med tiden blev din sida mer och mer läsbar och då insåg du att för ännu större popularitet måste du lägga till lite funktionalitet till webbplatsen eller helt enkelt automatisera en del av den åtgärden.

Du går till "lagret" av wordpress plugins och upptäcker att plugin du behöver inte finns där. Vad ska man göra? Vad ska jag göra? Om du åtminstone är lite bekant med grunderna i programmering i PHP, layout, så kommer det inte att vara svårt för dig Skriv ett plugin för WordPress själv.

Låt oss nu gå till "köket" för att förbereda vårt plugin.

P.s. Om du inte har kunskaper i php och layout... oroa dig inte, be någon att skriva de nödvändiga funktionerna till dig :)

Innan du börjar skriva ett plugin behöver du hänvisa till WordPress-dokumentationen som beskriver de grundläggande principerna för att skriva plugins och några kodexempel.

Jag kommer inte att duplicera denna information, utan går direkt till att skriva koden.

Låt oss skriva ett enkelt plugin som låter dig spara och visa recensioner om din webbplats. Naturligtvis finns sådana plugins redan, men detta kommer att fungera bra som ett exempel.

Det första vi kommer att göra är att komma på ett unikt namn för vårt plugin - " AdvUserReviews«.

Därefter kommer vi att skapa en ny katalog "advuserreviews" i katalogen på din webbplats "/wp-content/plugins/". Och i den kommer vi att skapa en fil "advuserreviews.php". Detta kommer att vara huvudfilen som kommer att ansvara för allmän initiering. (Det är lämpligt att använda UTF-8-kodning för filer).

Allra i början av filen måste du ange grundläggande information om plugin-programmet

Nu, om du går till kontrollpanelen, kan du se att systemet har hittat ett nytt plugin och erbjuder dig att aktivera det. Men det är för tidigt att göra det ännu.

Vi kommer att skriva vår nya plugin i OOP-stil och all databehandling kommer att finnas i en fil. Låt oss skapa huvudskelettet för filen.

// Stoppa direktanrop if(preg_match("#" . basename(__FILE__) . "#", $_SERVER["PHP_SELF"])) ( die("Du får inte anropa den här sidan direkt."); ) if (!class_exists("AdvUserReviews")) ( klass AdvUserReviews ( // Lagring av intern data offentlig $data = array(); // Objektkonstruktor // Initialisering av huvudvariabler funktion AdvUserReviews() ( ) ) ) global $rprice; $rprice = new AdvUserReviews();

Låt oss nu lägga till följande kod till objektkonstruktorn:

Funktion AdvUserReviews() ( global $wpdb; // Deklarera initialiseringskonstanten för vår plugin DEFINE("AdvUserReviews", true); // Filnamnet på vår plugin $this->plugin_name = plugin_basename(__FILE__); // URL-adress för vårt plugin $ this->plugin_url = trailingslashit(WP_PLUGIN_URL."/".dirname(plugin_basename(__FILE__))); // Tabell för att lagra våra recensioner // $wpdb-variabeln måste deklareras globalt $this->tbl_adv_reviews = $wpdb ->prefix . "adv_reviews"; // Funktion som körs när plugin-programmet aktiveras register_activation_hook($this->plugin_name, array(&$this, "activate")); // Funktion som exekveras när plugin-programmet avaktiveras register_deactivation_hook($this->plugin_name, array (&$this, "deactivate")); // Funktion som exekveras när en plugin avinstalleras register_uninstall_hook($this->plugin_name, array(&$this, "uninstall")); )

I objektkonstruktören använder vi 3 "krokar" eller "krokar" (vad är de?): register_activation_hook, register_deactivation_hook Och register_uninstall_hook- det här är de funktioner som utförs när plugin-programmet aktiveras, avaktiveras respektive raderas.

Låt oss nu implementera dessa funktioner direkt.

/** * Aktivera plugin */ function activate() ( global $wpdb; require_once(ABSPATH . "wp-admin/upgrade-functions.php"); $table = $this->tbl_adv_reviews; // Bestäm mysql-versionen if ( version_compare(mysql_get_server_info(), "4.1.0", ">=")) ( if (! tomt($wpdb->charset)) $charset_collate = "STANDARDTECKNSETT $wpdb->teckenuppsättning"; if (! empty( $wpdb->kollate)) $charset_collate .= "SAMLA $wpdb->kollate"; ) // Strukturen i vår tabell för recensioner $sql_table_adv_reviews = "SKAPA TABELL `".$wpdb->prefix."adv_reviews` (`Id` int (10) osignerad null auto_increment,` granskning_title` varchar (255) inte null standard "0", `granskning_text` text inte null,` granskning_date` timestamp inte null default current_timestamp, `granskning_user_name" (200) null , `review_user_email` VARCHAR(200) NULL, PRIMARY KEY (`ID`))".$charset_collate.";"; // Kontrollera om tabell existerar if ($wpdb->get_var("visa tabeller som "".$table .""" ) != $table) ( dbDelta($sql_table_adv_reviews); ) ) /** * Inaktivera plugin */ funktion deactivate() ( return true; ) /** * Ta bort en plugin */ funktion uninstall() ( global $wpdb; $wpdb->query("SLIPTA TABELL OM FINNS ($wpdb->prefix)adv_reviews"); )

Variabel $wpdb Ansvarig för frågor till databasen. Fungera dbDelta analyserar den aktuella tabellstrukturen, jämför den med den önskade tabellstrukturen och antingen lägger till eller modifierar tabellen efter behov.

Följaktligen, när plugin-programmet aktiveras, skapas en tabellstruktur för att lagra recensioner. När pluginet är avaktiverat sker ingen åtgärd, men när den raderas tar vi bort vår tabell. Åtgärderna kan förstås mer i detalj från källkoden.

Den grundläggande strukturen för det nya pluginet är klar. Nu måste vi börja skriva den funktionella delen. För att göra detta måste vi lägga till följande kodrader till klasskonstruktorn:

// Om vi ​​är i admin. gränssnitt if (is_admin()) ( // Lägg till stilar och skript add_action("wp_print_scripts", array(&$this, "admin_load_scripts")); add_action("wp_print_styles", array(&$this, "admin_load_styles")); // Lägg till en meny för plugin-programmet add_action("admin_menu", array(&$this, "admin_generate_menu")); ) else ( // Lägg till stilar och skript add_action("wp_print_scripts", array(&$this, "site_load_scripts" )) ; add_action("wp_print_styles", array(&$this, "site_load_styles")); add_shortcode("show_reviews", array (&$this, "site_show_reviews")); )

Låt oss titta på det här avsnittet av kod mer detaljerat. Låt oss börja med administrationspanelen.
Funktion" is_admin» kontrollerar i vilket läge vi arbetar just nu - på hemsidan eller i kontrollpanelen.
Därefter används flera krokar för funktioner:

• wp_print_scripts- Lägg till de nödvändiga javascript-filerna
• wp_print_styles- Lägg till de nödvändiga stilarna
• admin_menu- Lägga till en ny meny till kontrollpanelen

Varje krok motsvarar en implementerad metod i vår klass. Där de nödvändiga operationerna utförs.
Låt oss titta på koden för att ansluta stilar och skript

/** * Laddar de nödvändiga skripten för hanteringssidan * i administrationspanelen */ 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"); // Lägg till skript på sidan wp_enqueue_script("advReviewsAdminJs"); wp_enqueue_script("jquery"); ) /** * Laddar de nödvändiga stilarna för kontrollsidan * i administrationspanelen */ function admin_load_styles() ( // Register styles wp_register_style("advReviewsAdminCss", $this->plugin_url . "css/admin-style.css") ; // Lägg till stilar wp_enqueue_style( "advReviewsAdminCss"); )

Följande funktioner används här.

Varje åtgärd beror på den godkända parametern "action", respektive "edit" - redigera en recension, "submit" - spara en redigerad recension och "delete" - radera en recension.

Datautbyte med visningssidor sker genom objektegenskapen "data". Källkoden för dessa sidor kommer att publiceras i arkivet med denna modul i slutet av artikeln. Jag kommer inte att infoga dem här, eftersom ämnet redan är ganska stort.

Det är här vi avslutar med administrationspanelen och går vidare till att visa och lägga till recensioner från användare.

För att tala om för WordPress när vi ska ringa vårt plugin måste vi registrera "kortkod", vilket är vad som gjordes i konstruktören av vår klass. Läs mer om detta.

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

Nu kan du placera följande kod på vilken sida som helst på webbplatsen och den kommer att tvinga funktionen som vi angav (godkänd som den andra parametern) att köras. Nedan finns källkoden för denna funktion.

/** * Lista över recensioner på webbplatsen */ public function site_show_reviews($atts, $content=null) ( global $wpdb; if (isset($_POST["action"]) && $_POST["action"] = = " add-review") ( $this->add_user_review(); ) // Välj alla recensioner från databasen $this->data["reviews"] = $wpdb->get_results("SELECT * FROM `" . $ this- >tbl_adv_reviews . "`", ARRAY_A); ## Aktivera utgångsbuffring ob_start (); include_once("site_reviews.php"); ## Ta emot data $output = ob_get_contents (); ## Inaktivera buffring ob_end_clean (); return $output ; ) privat funktion 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"]),); // Lägg till en ny recension på webbplatsen $wpdb->insert( $this-> tbl_adv_reviews, $inputData); )

I princip är det inget komplicerat här - en SQL-fråga görs för att välja data, men om parametern "action" passeras läggs först en ny recension till. Men det är värt att uppmärksamma utdatabuffring. Det är nödvändigt för att få data från den infogade sidan.

Det är allt. Nu kan vi se vad vi har. A ladda ner plugin och källkoder du kan här.

Naturligtvis är detta bara ett exempel på att skapa ett plugin, men det kommer också att fungera som en enkel gästapp om du modifierar den lite, till exempel genom att lägga till skydd mot bots och sida-för-sida-utdata. Lycka till med kodningen :)

Formulär på hemsidan:

Plugin kontrollpanel:

Redigeringsrecension:

Du kanske också är intresserad av:

Alla nybörjare webbansvariga är rädda och avskräckta av att arbeta med kod – de är rädda för att skada sin webbplats genom att lägga till HTML eller PHP på den, eller infoga den på fel ställe. Om du lägger koden på fel ställe i WordPress kan du förstås förstöra allt. Detta CMS är dock så väl anpassat för nybörjare att det blir svårt att göra fel.

I den här artikeln kommer vi att titta på hur du säkert infogar HTML- eller PHP-kod i WordPress. Men först, varför detta kan vara användbart.

Varför bädda in kod i WordPress

Under sajtens livslängd kan webbmastern behöva installera kod på WordPress som måste köras på sidorna. Detta kan behövas av olika anledningar: till exempel installera en trafikräknare, någon ovanlig widget eller lägga till personlighet till mallen.

WordPress erbjuder två sätt att installera koden. Låt oss titta på dem.

Installation med hjälp av textwidgeten

För att installera kod på WordPress med hjälp av en widget måste du gå till menyalternativet i "Utseende"-konsolen och underposten "Widgets". Bland dem bör du hitta "Text" och flytta den till önskat område med musen.

Widgeten öppnas och du kan fylla i dess titel, samt placera den nödvändiga koden i lämpligt fält. Efter att ha klickat på "Spara"-knappen kommer operationen att utföras på webbplatsens sidor.

Denna metod för att installera kod på WordPress är lämplig för att utföra operationer i HTML, PHP och till och med JavaScript. Denna metod används ofta för att den är enkel och fungerar bra för nybörjare.

Installation till fil

Att installera kod på WordPress med filredigering rekommenderas inte för nybörjare, men förr eller senare måste alla behärska det. Den här metoden är praktisk eftersom HTML eller PHP kan placeras i vilken del som helst, inte bara i widgetområdet, som beskrivs i den första metoden. Nackdelen med denna installationsmetod är att den kan vara farlig och om det görs fel kan det leda till att sidan inte fungerar. Innan du använder den här metoden måste du därför göra en säkerhetskopia av dina filer och databas.

För att installera kod direkt i en fil på WordPress måste du veta vilket område på webbplatsen en viss fil är ansvarig för. Det är omöjligt att ge exakta rekommendationer här, eftersom olika filer i olika mallar utför vissa funktioner. Däremot kan du lära dig något om temafiler. Förutom att installera koden i mallfilen på WordPress kan detta även göras i själva CMS:s filer.

Kodläsbarhet är ett mycket känsligt ämne och måste ägnas vederbörlig uppmärksamhet. I den här artikeln kommer du att lära dig 16 tekniker som hjälper dig att komma vidare i detta ämne.

1. Kommentarer och dokumentation

IDE:er blir allt mer populära i utvecklarvärlden eftersom... de tillhandahåller praktiska verktyg för att kommentera och dokumentera kod.

Här är ett exempel:

Här är ett annat exempel på att kalla din egen metod:

I det här exemplet är kommentarsstilen baserad på PHPDoc, och IDE jag använder är Aptana.

2. Indrag

Jag antar att du redan vet vikten av indrag i din kod. I allmänhet finns det flera stilar av kodformatering.

Funktion foo() ( if ($maybe) ( do_it_now(); again(); ) else ( abort_mission(); ) finalize(); )

Funktion foo() ( if ($maybe) ( do_it_now(); again(); ) else ( abort_mission(); ) finalize(); )

Funktion foo() ( if ($maybe) ( do_it_now(); again(); ) else ( abort_mission(); ) finalize(); )

Själv använder jag oftast stil #2, men ibland byter jag till #1. Men allt detta är förstås en smaksak. Troligtvis finns det ingen "bästa" stil som skulle passa absolut alla. Dessa regler måste först och främst följas av de som arbetar i ett team eller deltar i att skriva projekt med öppen källkod.

Det finns också stilar som kombinerar vissa egenskaper. Till exempel PEAR-kodskrivningsstandarderna, där det krulliga klammerparentesen "(" i villkorliga uttalanden förblir på samma rad, men flyttas i funktioner.

PEAR stil:

Funktion foo() ( // på en ny rad if ($maybe) ( // på samma rad do_it_now(); again(); ) else ( abort_mission(); ) finalize(); )

Det bör också noteras att denna stil använder 4 mellanslag istället för tabbar.

Du kan lära dig mer om de olika stilarna.

3. Undvik onödiga kommentarer

Ja, kommentarskoden är bra; men det finns ingen anledning att överdriva det. Här är ett exempel:

// hämta landskoden $country_code = get_country_code($_SERVER["REMOTE_ADDR"]); // om landet är USA if ($country_code == "US") ( // visa formuläret echo form_input_state(); )

Om kodens arbete är uppenbart, bör du troligen inte skriva onödiga kommentarer.

Om du inte har dem kan du förkorta dem lite:

// visa formuläret om landet är US $country_code = get_country_code($_SERVER["REMOTE_ADDR"]); if ($country_code == "US") ( echo form_input_state(); )

4. Kodgruppering

Oftast kräver vissa uppgifter att du skriver flera rader kod. Därför är det bäst att kombinera sådana uppgifter i separata block åtskilda av mellanslag.

Här är ett enkelt exempel:

// få listan över forum $forums = array(); $r = mysql_query("VÄLJ ID, namn, beskrivning FRÅN forum"); while ($d = mysql_fetch_assoc($r)) ( $forums = $d; ) // ladda mallen load_template("header"); load_template("forum_list",$forum); load_template("sidfot");

Om du lägger till en kommentar före början av varje block kommer detta att förbättra läsbarheten för din kod ytterligare.

5. Namnschema

Ibland även i PHP-språket kan du hitta inkonsekvenser i namngivningsfunktioner. Och här är många exempel:

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

Det finns flera populära stilar:

• camelCase: versaler den första bokstaven i varje nytt ord.
• understreck: Understreck mellan ord: mysql_real_escape_string().

Om du blandar dessa tekniker kan du förr eller senare hamna i en besvärlig situation. Om du arbetar med ett projekt som använder någon av dessa tekniker, vill du följa efter. Detta kan fortfarande bero på programmeringsspråket. Till exempel använder de flesta Java-utvecklare camelCase, medan PHP-utvecklare föredrar understreck.

Men även här fanns en hybrid. Vissa utvecklare använder understreck för att namnge klasser och metoder (utanför klasser), och i andra fall använder camelCase:

Klass Foo_Bar ( offentlig funktion someDummyMethod() ( ) ) funktion procedural_function_name() ( )

Än en gång kommer jag att säga att det inte finns någon bästa stil. Du måste bara hålla dig till något.

6. DRY princip

DRY (Don't Repeat Yourself) - upprepa inte dig själv. Även känd som DIE: Duplication is Evil.

Huvuduppgiften för alla system, oavsett om det är en webbapplikation eller något annat, är att automatisera repetitiva uppgifter. Denna princip bör följas alltid och överallt, speciellt om du är en utvecklare. Samma kodbit ska inte upprepas om och om igen.

Till exempel består de flesta webbapplikationer av en eller flera sidor. Det är tydligt att dessa sidor kommer att innehålla samma element. Sidhuvud och sidfot är de mest slående exemplen. Du skulle bli förvånad över hur många som fortfarande duplicerar dessa element på varje sida.

$this->load->view("includes/header"); $this->load->view($main_content); $this->load->view("inkluderar/sidfot");

7. Undvik djup häckning

Kodens läsbarhet minskar kraftigt om du har djup häckning.

Funktion do_stuff() ( // ... if (is_writable($folder)) ( if ($fp = fopen($file_path,"w")) ( if ($stuff = get_some_stuff()) ( if (fwrite($ fp,$stuff)) ( // ... ) else ( return false; ) ) else ( return false; ) ) else ( return false; ) ) else ( return false; ) )

För att rätta till situationen bör du ompröva hur din kod fungerar och optimera den:

Funktion do_stuff() ( // ... if (!is_writable($folder)) ( return false; ) if (!$fp = fopen($file_path,"w")) ( return false; ) if (!$stuff = get_some_stuff()) ( return false; ) if (fwrite($fp, $stuff)) ( // ... ) else ( return false; ) )

8. Linjelängdsgräns

Alla vet att läsprocessen blir mycket roligare när texten är indelad i kolumner. Detta är den främsta anledningen till att våra tidningar ser ut så här:

En liknande teknik kan tillämpas på vår kod:

// dålig $my_email->set_from(" [e-postskyddad]")->add_to(" [e-postskyddad]")->set_subject("Methods Chained")->set_body("Något långt meddelande")->send(); // bra $my_email ->set_from(" [e-postskyddad]") ->add_to(" [e-postskyddad]") ->set_subject("Methods Chained") ->set_body("Något långt meddelande") ->send(); // dålig $query = "VÄLJ ID, användarnamn, förnamn, efternamn, status FRÅN användare VÄNSTER GÅ MED user_posts ANVÄNDA (users.id, user_posts.user_id) WHERE post_id = "123""; // dåligt $query = "VÄLJ id, användarnamn, förnamn, efternamn, status FRÅN användare VÄNSTER JOIN user_posts USING(users.id, user_posts.user_id) WHERE post_id = "123"";

De flesta utvecklare håller sig till 80 och 120 teckengränser.

9. Organisera filer och mappar

Tekniskt sett kan du lägga all kod för din applikation i en fil :) Men vad gör du när du behöver ändra eller lägga till något.

Jag minns mina första projekt där jag bifogade filer. Men min organisation var mycket dålig. Jag skapade en "inc"-mapp där jag placerade flera filer: db.php och functions.php. Under processen att skriva ansökan växte den här mappen sig större och större och i slutändan var det svårt att lista ut vad som fanns var.

För att lösa detta problem är det bättre att använda olika typer av ramar eller åtminstone hålla sig till deras struktur. Så här ser projektet ut på CodeIgniter:

10. Variabelnamn

Generellt sett bör variabelnamn vara helt meningsfulla - detta är det perfekta fallet. Ett undantag kan göras för temporära variabler.

Låt oss titta på några exempel:

// $i för för loopar ($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 och $d för mysql $q = "SELECT * FROM table"; $r = mysql_query($q); while ($d = mysql_fetch_assocr($r)) ( ) // $fp för att arbeta med filer $fp = fopen("file.txt","w");

11 - Skriv nyckelord i SQL med versaler

De flesta webbapplikationer interagerar med databaser. Om du själv skriver SQL-frågor måste de också formateras därefter... Det är inget komplicerat här. Skriv bara dina sökord med versaler.

12. Separera kod och data

Detta är en annan princip som hjälper dig att skriva mer begripliga program. Det innebär att förbereda data på ett ställe (till exempel modeller) och interagera med det på ett annat.

När PHP först började utvecklas var det mer som ett mallsystem. Projekt på detta språk innehöll blandad HTML- och PHP-kod. Nu har allt förändrats, och alla borde gå till nästa nivå av ansökningsskrivning.

Du kan utveckla en speciell stil för dig själv, eller så kan du använda de mest populära medlen idag.

Populära PHP-ramverk:

Mallsystem:

Populärt CMS

13. Speciell syntax för mallar

Om du inte vill använda ett mallsystem måste du med största sannolikhet utveckla din egen stil för att bädda in PHP-kod i HTML.

Och här är ett exempel:

Min anslagstavla

Denna teknik låter dig undvika onödiga parenteser. Sådan kod passar också bra in i HTML-kontexten.

14. Procedurmässiga och objektorienterade tillvägagångssätt

Objektorienterad programmering hjälper dig att hålla dig till en mer eller mindre tydlig struktur, men det betyder inte att du ska avvika från de processuella principerna för att skriva ansökningar.

Objekt är utmärkta för att representera data. Exempel:

Klassanvändare ( public $username; public $first_name; public $last_name; public $email; public function __construct() ( // ... ) public function create() ( // ... ) public function save() ( / / ... ) public function delete() ( // ... ) )

Procedurmetoder har sina egna specifika fördelar.

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

15. Läs öppen källkod

Vanligtvis skrivs Open Source-projekt av ett stort antal utvecklare. Ur denna synvinkel kan du få erfarenhet av att studera den skrivna koden i liknande projekt. Så slösa inte din tid på detta.

16. Refaktorering

Refaktorering är att ändra kod utan att förlora funktionalitet. Det kan också användas för att förbättra läsbarheten.Det finns inget utrymme för att fixa buggar eller lägga till funktionalitet. Du ändrar bara strukturen på din kod lite.

Jag hoppas att du tyckte att den här artikeln var till hjälp! Har jag missat något? Dela din upplevelse!

Jag vågar anta att det har funnits tillfällen i ditt liv då du velat lägga till (rätta) något till temat på din WP-sajt, eller till funktionaliteten hos någon plugin. Dessutom inkluderade utvecklarna inte denna funktion i standardkontroller. Och din själ känner inte igen några begränsningar och kräver fantasier :) Som du förstår finns det en väg ut ur alla situationer, i det här fallet måste vi korrigera koden för plugin, tema...

Den största svårigheten med att redigera kod är att ändringarna du gör, tyvärr, inte sparas länge, och kommer med största sannolikhet att avbrytas under nästa uppdatering. Om lösningen du ser är att undvika uppdateringar så vågar jag avråda dig från detta farliga ovärdiga beslut, eftersom uppdateringar innehåller viktiga förändringar vad gäller säkerhet och buggfixar och ofta även tillför nya funktioner.

Som ett resultat är det att föredra att använda metoder som kommer att stå sig i vår dynamiskt föränderliga värld och samtidigt spara din dyrbara tid.

Varningar!

På Internet kan du ofta hitta råd som föreslår att du gör ändringar i filen functions.php- om det finns någon möjlighet att klara sig utan detta är det bättre att inte röra den här filen. I metoderna nedan ser du ett sätt att implementera detta. Och i alla fall måste du skapa ett barntema och inte röra föräldern.

När du lägger till prefix till en funktion, använd alltid anpassad kod i formen: _prefix(till namnet på den funktion som ändras). Denna åtgärd kommer att skydda dig från konflikter med andra funktioner i temat eller plugin.

Så, hur lägger du till kod till en WP-webbplats?

1) Anpassat plugin

På så sätt kan du infoga kodsnuttar, och de kommer inte att raderas under uppdateringen, och du kan även redigera, aktivera dem i framtiden eller vice versa - avaktivera dem vid behov.

Detta är lätt att göra: först måste du skapa en katalog för ditt plugin och namnge det därefter, till exempel moy-plugin (använd bara bindestreck, inte understreck)

Därefter skapar vi huvudpluginfilen. Som du förstår bör den innehålla ett namn, beskrivning och grundläggande information, samt kod som hjälper till att skydda plugin-programmet från inkräktare. Och vi kallar den här filen, låt oss säga moy-plugin.php. Tillägget .php kommer att tala om för WP vilket språk filen skapades på.

Du kan skapa en fil med metoden som beskrivs ovan i vilken textredigerare som helst, till exempel NotePad, som redan är noggrant installerad i Windows-operativsystemet (TextEdit på Mac). Det är bättre att inte använda Microsoft Word-redigeraren, eftersom den formaterar texten, och vi behöver den absolut inte i den här situationen.

Så här är koden att lägga till:

Och under den här koden gör du dina ändringar som din kreativa själ kräver. Det finns ingen anledning att lägga till avslutande PHP-taggar i slutet. I det här fallet kommer namnet, beskrivningen och webbadressen att visas på din adminpanel. Och naturligtvis kan du ersätta "ClubWP"-informationen med din egen information

Efter det återstår bara att packa det du har skapat i ett zip-arkiv och skicka det till din webbplats ftp. I framtiden kan du på detta sätt göra eventuella ändringar i ditt plugin.

På det här enkla sättet skapar du en enkel plugin för dina behov.

2) Code Snippets plugin

Om metoden som beskrivs ovan är svår för dig, eller om du är en mycket praktisk person och är van vid att få resultat snabbare, skapades Code Snippets speciellt för dig. Precis som funktionen som beskrivs ovan, lägger plugin till din kod med möjligheten att ytterligare redigera den utan att använda ditt tema.

Efter installation av plugin-programmet kommer ett nytt "Snippets"-fönster att visas i adminpanelen, där du kan lägga till nya snippets. För vilken du kan ange en kod och information om dess syfte.

Således har du möjlighet att aktivera eller inaktivera anpassad kod i form av plugins. Mycket bekvämt och praktiskt eftersom... Ibland kan det uppstå konflikter med teman och plugins, och du kan enkelt förstå detta och inaktivera den genererade koden.

3) Redigera Functions.php av ett barntema

Om användningen av plugins inte är lämplig för dig och du behöver göra ändringar direkt i temat på din webbplats, då är den här metoden för dig. Låt mig påminna dig om att du bara kan göra detta med barnteman.

För att använda denna metod erbjuder jag min mall functions.php barn tema. Packa upp och redigera filen style.css(mallnamn och import-URL)

P.S. Försök att göra allt för att förenkla ditt liv i framtiden, inklusive din hårda del av att eliminera buggar och redigera anpassad kod när behovet uppstår.