Sugestões para organizar o código de procedimento
Por mais que eu escreva – e seja fã de – programação orientada a objetos, não escrevo muito sobre os tempos em que estou trabalhando com uma base de código procedural.
A programação procedural é um paradigma de programação, derivado da programação estruturada, baseado no conceito de chamada de procedimento. Os procedimentos, também conhecidos como rotinas, sub-rotinas ou funções, contêm simplesmente uma série de etapas computacionais a serem executadas.
Às vezes, eu recebo isso dos requisitos de um projeto, às vezes é de um projeto que herdei, ou às vezes por causa de outra coisa.
Acho importante que, como programadores, não tenhamos um paradigma tão alto que evitemos trabalhar com outras formas de escrever código. Afinal, o ato de escrever código é, em sua essência, resolver um problema.
Como o problema é resolvido pode ser considerado secundário.
Independentemente disso, sempre que estou trabalhando com uma base de código; no entanto, está escrito, ainda tento garantir que seja organizado de maneira coesa, o mais fácil de seguir possível e capaz de ser mantido ao longo do tempo.
Eu pensei em compartilhar como eu abordo a escrita de plugins WordPress usando programação procedural versus programação orientada a objetos e como eu organizo o código procedural.
Se nada mais, talvez isso lhe dê algumas idéias para um projeto atual ou futuro.
Organizando o Código de Procedimento
Quando se trata de trabalhar com código procedural, há muito potencial para incluir quase tudo em um único arquivo monolítico.
Eu não sou dessa abordagem porque torna mais difícil encontrar onde algo reside no arquivo (pelo menos se você for alguém que está entrando em um projeto).
Para esse fim, estas são as coisas que eu costumo fazer.
- Ações e Filtros Separados. Normalmente, eu pego todas as ações e as coloco em um arquivo e eu pego todos os filtros e os coloco em outro arquivo. Também é possível separar ainda mais esses arquivos em subdiretórios (se não em namespaces também) com base em suas áreas de foco. Por exemplo, qualquer ação relacionada à área de administração pode ir para um subdiretório admin .
- Escreva um arquivo de depuração. Eu normalmente incluo um script de depuração simples em um plug-in para que eu possa facilmente renderizar informações de depuração na tela, gravar no arquivo de log de depuração ou gravar em ambos. Isso pode ser uma conveniência, se nada mais, mas ajuda a fornecer uma maneira de ver facilmente o que está acontecendo sem a necessidade de iniciar o Xdebug e percorrer o código (a menos que seja um problema mais complicado).
- Carregador automático. Se você estiver usando código procedural, talvez não esteja usando namespaces, mas, se estiver, também incluo um carregador automático que escrevi para facilitar a inclusão de arquivos automaticamente. Isso é diferente do autoloader que o Composer gera, mas ainda faz a mesma coisa.
Obviamente, não há nada inerentemente complicado nas recomendações acima. Na verdade, eu diria que qualquer uma das opções acima, especialmente a primeira etapa, pode ajudar bastante a melhorar a capacidade de gerenciamento do código procedural.
O arquivo de plug-in principal
Se você optar por fazer todas as opções acima, a versão final do arquivo bootstrap do plug-in deve ser muito simples. Na verdade, pode parecer algo tão simples como isto :
<?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';
Novamente, isso pressupõe que você esteja aplicando todas as três recomendações. Caso contrário, sua implementação pode variar.