Bo o ile piszę – i jestem fanem – programowania obiektowego, to niewiele piszę o czasach, w których pracuję z bazą kodu proceduralnego.
Programowanie proceduralne to paradygmat programowania wywodzący się z programowania strukturalnego, oparty na koncepcji wywołania procedury. Procedury, znane również jako procedury, podprogramy lub funkcje, zawierają po prostu serię kroków obliczeniowych do wykonania.
Czasami dochodzę do tego z wymagań projektu, czasami z projektu, który odziedziczyłem, a czasami z czegoś innego.
Myślę, że ważne jest, abyśmy jako programiści nie trzymali się jednego paradygmatu na tyle wysoko, że unikalibyśmy pracy z innymi sposobami pisania kodu. W końcu akt pisania kodu polega w istocie na rozwiązaniu problemu.
Sposób rozwiązania problemu można uznać za drugorzędny.
Niezależnie od tego, kiedy pracuję z bazą kodu; jednak jest napisane, nadal staram się, aby była zorganizowana w sposób spójny, jak najłatwiejszy do naśladowania i możliwy do utrzymania w czasie.
Pomyślałem, że podzielę się tym, jak podchodzę do pisania wtyczek do WordPressa za pomocą programowania proceduralnego w porównaniu z programowaniem obiektowym i jak organizuję kod proceduralny.
Jeśli nic więcej, być może da ci to pomysły na obecny lub przyszły projekt.
Organizacja kodu proceduralnego
Jeśli chodzi o pracę z kodem proceduralnym, istnieje duży potencjał na umieszczenie prawie wszystkiego w jednym, monolitycznym pliku.
Nie jestem zwolennikiem tego podejścia, ponieważ utrudnia to znalezienie miejsca, w którym coś znajduje się w pliku (przynajmniej jeśli jesteś kimś, kto dopiero wchodzi do projektu).
W tym celu to są rzeczy, które zwykle robię.
- Oddzielne akcje i filtry. Zazwyczaj wykonuję wszystkie działania i umieszczam je w jednym pliku, a wszystkie filtry umieszczam w innym pliku. Możliwe jest również dalsze rozdzielenie tych plików na podkatalogi (jeśli nie również przestrzenie nazw) na podstawie ich obszarów zainteresowania. Na przykład wszelkie akcje związane z obszarem administracyjnym mogą znajdować się w podkatalogu admin .
- Napisz plik debugowania. Zwykle dołączam prosty skrypt debugowania do wtyczki, dzięki czemu mogę łatwo wyświetlać informacje debugowania na ekranie, pisać do pliku dziennika debugowania lub pisać do obu. Może to być wygodne, ale pomaga w łatwy sposób zobaczyć, co się dzieje, bez konieczności uruchamiania Xdebug i przechodzenia przez kod (chyba że jest to bardziej skomplikowany problem).
- Autoloader. Jeśli używasz kodu proceduralnego, możesz w ogóle nie używać przestrzeni nazw, ale jeśli tak, dołączam również autoloader, który napisałem, aby ułatwić automatyczne dołączanie plików. Jest to coś innego niż autoloader niż generowany przez Composer, ale nadal robi to samo.
Oczywiście w powyższych zaleceniach nie ma nic z natury skomplikowanego. W rzeczywistości powiedziałbym, że którykolwiek z powyższych, zwłaszcza pierwszy krok może znacznie poprawić łatwość zarządzania kodem proceduralnym.
Główny plik wtyczki
Jeśli zdecydujesz się wykonać wszystkie powyższe czynności, ostateczna wersja pliku startowego wtyczki powinna być naprawdę prosta. W rzeczywistości może to wyglądać na coś tak prostego jak to :
<?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';
Ponownie, zakładamy, że stosujesz wszystkie trzy zalecenia. Jeśli nie, Twoja implementacja może się różnić.