Пропозиції щодо організації процесуального кодексу

Останнє оновлення Гру 21, 2022

Зміст

Незважаючи на те, що я пишу про об’єктно-орієнтоване програмування – і є його прихильником – я мало пишу про часи, коли я працюю з базою процедурного коду.

Процедурне програмування — це парадигма програмування, похідна від структурованого програмування, заснована на концепції виклику процедури. Процедури, також відомі як підпрограми, підпрограми або функції, просто містять серію обчислювальних кроків, які необхідно виконати.

Іноді я приходжу до цього через вимоги проекту, іноді це через проект, який я успадкував, або іноді через щось інше.

Я вважаю, що важливо, щоб ми, як програмісти, не трималися однієї парадигми настільки високо, щоб уникати роботи з іншими способами написання коду. Зрештою, акт написання коду, за своєю суттю, стосується вирішення проблеми.

Спосіб вирішення проблеми можна вважати другорядним.

Незважаючи на це, коли я працюю з кодовою базою; однак, це написано, я все ще намагаюся переконатися, що це організовано так, щоб це було зв’язано, якомога легше дотримуватись і щоб його можна було підтримувати з часом.

Я подумав поділитися тим, як я підходжу до написання плагінів WordPress за допомогою процедурного програмування проти об’єктно-орієнтованого програмування та як я підходжу до організації процедурного коду.

Якщо нічого іншого, можливо, це дасть вам кілька ідей для поточного чи майбутнього проекту.

Організаційний процесуальний кодекс

Коли справа доходить до роботи з процедурним кодом, існує великий потенціал для включення майже всього в єдиний монолітний файл.

Я не прихильник цього підходу, тому що це ускладнює пошук того, де щось знаходиться у файлі (принаймні, якщо ви тільки починаєте проект).

З цією метою я зазвичай роблю це.

Окремі дії та фільтри. Як правило, я виконую всі дії та поміщаю їх в один файл, а всі фільтри – в інший файл. Також можна додатково розділити ці файли на підкаталоги (якщо не на простори імен) на основі їхньої сфери фокусування. Наприклад, будь-які дії, пов’язані з областю адміністрування, можуть передаватись у підкаталог admin .
Напишіть файл налагодження. Зазвичай я включаю простий сценарій налагодження в плагін, щоб я міг легко відтворювати інформацію про налагодження на екрані, записувати файл журналу налагодження або писати в обидва. Це може бути зручністю, якщо нічого іншого, але це допомагає забезпечити спосіб легко побачити, що відбувається без необхідності запускати Xdebug і покроково переглядати код (якщо це не більш складна проблема).
Автозавантажувач. Якщо ви використовуєте процедурний код, можливо, ви взагалі не використовуєте простори імен, але якщо так, то я також додаю автозавантажувач, який я написав, щоб полегшити автоматичне включення файлів. Це відрізняється від автозавантажувача, ніж генерує Composer, але все одно робить те саме.

Очевидно, що в наведених вище рекомендаціях немає нічого складного. Фактично, я б сказав, що будь-який із перерахованих вище кроків, особливо перший, може значно покращити керованість процедурним кодом.

Основний файл плагіна

Якщо ви вирішите зробити все вищезазначене, остаточна версія файлу початкового завантаження плагіна має бути дуже простою. Насправді це може виглядати так просто :

<?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';

Знову ж таки, це припускає, що ви застосовуєте всі три рекомендації. Якщо ні, то ваша реалізація може відрізнятися.

Джерело запису: tommcfarlin.com