Предложения по организации процессуального кодекса
Несмотря на то, что я пишу об объектно-ориентированном программировании и являюсь его поклонником, я мало пишу о временах, когда я работал с базой процедурного кода.
Процедурное программирование — это парадигма программирования, полученная из структурного программирования и основанная на концепции вызова процедуры. Процедуры, также известные как подпрограммы, подпрограммы или функции, просто содержат ряд вычислительных шагов, которые необходимо выполнить.
Иногда я прихожу к этому из требований проекта, иногда из проекта, который я унаследовал, а иногда из-за чего-то еще.
Я думаю, важно, чтобы мы, программисты, не слишком высоко ставили одну парадигму, чтобы не уклоняться от работы с другими способами написания кода. В конце концов, процесс написания кода — это, по сути, решение проблемы.
Способ решения проблемы можно считать второстепенным.
Независимо от того, когда я работаю с кодовой базой; тем не менее, он написан, и я по-прежнему стараюсь удостовериться, что он организован таким образом, чтобы он был связным, как можно более простым для понимания и чтобы его можно было поддерживать в течение долгого времени.
Я решил поделиться своим подходом к написанию плагинов 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';
Опять же, это предполагает, что вы применяете все три рекомендации. Если нет, то ваша реализация может отличаться.