v2.x Code Style - Getbeans/Beans GitHub Wiki
Beans 2.0 will be based upon PHP 5.6 while protecting for PHP 7 and up.
Where possible, we will be WordPress Coding Standards (WPCS) compliant. However, we will deviate with the power and flexibility of PHP 5.6, PSR-4, and namespaces.
Simple interfaces. Inner-workings tucked away.
It's a different mindset: coding code such that it exposes simple endpoints and functionality without having to know about the inner-workings. (BTW, It's core principle of OOP, if you're familiar.)
Let me give you a visual: turning on your car. Think about the process it takes to turn on your car. If you have a remote start, you click a button and it starts. Otherwise, you sit down and either press a button or turn the key to start it. There are steps and circuits that need to fire in a particular sequence for a car to start. But you don't have to worry about it. Right? The car handles it for you, tucking (hiding) away the complexity and inner-workings.
Hold that visual in your mind.
Imagine if you had to trigger all of the steps and circuits yourself instead of just pressing a button, app, or turning a key. Argh, that would be time-consuming and incredibly frustrating. Right?
Think about this. If you had to manually do all the steps, you'd likely do one out of order or misfire and break it. Oh bummer.
Hiding away complexity while exposing simple interfaces is the same thing. Make it easy to use and customize it, but prevent error and frustrations by hiding all the nitty gritty away.
Files will be namespaced with the exception of prefixed, globally available API functions.
Note: Namespacing came in, in PHP 5.3.0. That means all Beans versions before 2.0 will use prefixing and not namespacing.
The Beans namespace will be:
for the framework. Following PSR-4 standards, each folder represents a single unit (module, package, or sub). The folder's name is part of the namespace.
Huh? Let me give you an example:
beans lib API Actions // would be namespace: namespace Beans\BeansFramework\API\Actions;
The filesystem will follow PSR-4 + WordPress standard. By marrying the two together, we get the advantage of autoload along with WordPress familiarity and compliance (well-mostly).
Functions and Methods
Follow WordPress' naming standards, meaning:
- lowercase letters
The exposed functions, i.e. those the child theme and plugins will use, will be prefixed and not namespaced. Naming follows this convention:
Functions do work, such as render, run, check, do, process, etc. Work means they are action-based, i.e. verbs.
The description tells you what the expected behavior is when you call this function. It's clear and expressive. Remember the intent: It tells you the expected behavior.
The benefit to that naming convention is: you can read the function's name and know what will happen when you call it.
..... more to come.....