Ehdotuksia menettelysäännöstön järjestämiseksi

Niin paljon kuin kirjoitan – ja olen sen fani – olio-ohjelmointi, en kirjoita paljoakaan ajasta, jolloin työskentelen prosessikoodipohjan kanssa .

Proseduuriohjelmointi on ohjelmointiparadigma, joka on johdettu strukturoidusta ohjelmoinnista, joka perustuu proseduurikutsun käsitteeseen. Proseduurit, jotka tunnetaan myös rutiineina, alirutiineina tai funktioina, sisältävät yksinkertaisesti sarjan suoritettavia laskennallisia vaiheita.

Joskus tulen tähän jonkin projektin vaatimuksista, joskus se tulee projektista, jonka olen perinyt, tai joskus jostain muusta syystä.

Mielestäni on tärkeää, että ohjelmoijana emme pidä yhtä paradigmaa niin korkealla, että vältämme työskentelemästä muiden koodinkirjoitustapojen kanssa. Loppujen lopuksi koodin kirjoittaminen on pohjimmiltaan ongelman ratkaisemista.

Ongelman ratkaisemista voidaan pitää toissijaisena.

Siitä huolimatta, aina kun työskentelen koodipohjan kanssa; Kuitenkin, se on kirjoitettu, yritän silti varmistaa, että se on järjestetty yhtenäisellä, mahdollisimman helposti seurattavalla tavalla ja sitä voidaan ylläpitää ajan myötä.

Ajattelin kertoa, kuinka suhtaudun WordPress-laajennusten kirjoittamiseen proseduuriohjelmoinnin ja olioohjelmoinnin avulla ja miten järjestän prosessikoodin.

Jos ei muuta, ehkä tämä antaa sinulle ideoita nykyiseen tai tulevaan projektiin.

Järjestämisen menettelysäännöstö

Proseduurikoodin kanssa työskentelyssä on paljon mahdollisuuksia sisällyttää melkein kaikki yhteen monoliittiseen tiedostoon.

En hyväksy tätä lähestymistapaa, koska se vaikeuttaa tiedostossa olevan sisällön löytämistä (ainakin jos olet juuri tulossa projektiin).

Tätä varten teen yleensä näitä asioita.

1. Erilliset toiminnot ja suodattimet. Tyypillisesti teen kaikki toiminnot ja sijoitan ne yhteen tiedostoon ja otan kaikki suodattimet ja sijoitan ne toiseen tiedostoon. On myös mahdollista jakaa nämä tiedostot edelleen alihakemistoihin (ellei myös nimiavaruuksiin) niiden painopistealueiden perusteella. Esimerkiksi kaikki hallinta-alueeseen liittyvät toiminnot voivat mennä järjestelmänvalvojan alihakemistoon.
2. Kirjoita virheenkorjaustiedosto. Yleensä sisällytän laajennukseen yksinkertaisen virheenkorjauskomentosarjan, jotta voin helposti näyttää virheenkorjaustiedot näytöllä, kirjoittaa virheenkorjauslokitiedostoon tai kirjoittaa molempiin. Tämä voi olla kätevä, jos ei muuta, mutta se auttaa tarjoamaan tavan nähdä helposti mitä tapahtuu ilman, että sinun tarvitsee käynnistää Xdebugia ja käydä läpi koodia (ellei kyseessä ole monimutkaisempi ongelma).
3. Autoloader. Jos käytät prosessikoodia, et ehkä käytä nimiavaruuksia ollenkaan, mutta jos käytät, sisällytän mukaan myös automaattisen latausohjelman, jonka olen kirjoittanut tiedostojen automaattisen sisällyttämisen helpottamiseksi. Tämä on erilainen kuin automaattinen latausohjelma kuin Composer luo, mutta se tekee silti saman asian.

On selvää, että yllä olevissa suosituksissa ei ole mitään luonnostaan ​​monimutkaista. Itse asiassa sanoisin, että mikä tahansa edellä mainituista, varsinkin ensimmäinen askel, voi parantaa huomattavasti menettelykoodin hallittavuutta.

Päälaajennustiedosto

Jos päätät tehdä kaikki edellä mainitut, liitännäisen bootstrap-tiedoston lopullisen version pitäisi olla todella yksinkertainen. Itse asiassa se voi näyttää joltain näin yksinkertaiselta :

<?php
/**
 * Plugin Name: Acme Plugin
 * Plugin URI:  https://acmeplugins.com/acme
 * Description: This is the plugin description.
 * Version:     1.0.0
 * Author:      Acme Plugins Co.
 * Author URI:  https://acmeplugins.com/acme
 * License:     GPL-3.0+
 * License URI: http://www.gnu.org/licenses/gpl-3.0.txt
 *
 * @since   1.0.0
 * @package Acme
 */

namespace Acme;

defined( 'WPINC') || die;

// Include the custom autoloader.
require_once __DIR__. '/inc/autoload.php';

// Include action and filters.
require_once __DIR__. '/inc/actions.php';
require_once __DIR__. '/inc/filters.php';

Tämä taas edellyttää, että noudatat kaikkia kolmea suositusta. Jos ei, toteutus voi vaihdella.