In prior to having perfect docs, an MCP server, I collect some dev-rules here:
Modularity
Everything goes into packages. Many packages may ship with just one single entity. This cares for SRP. Entities that ship with relations ... always polymorphic.
Loose Coupling
Packages should mostly not be required, but configurable. Like with Relations, Taxonomies as array that allows multiple classes or like User (author model) and Scope by a single class assignement. In rare cases where config seems not useful, we use class_exists solely.
Sane Defaults
When things are configurable, those should be preconfigured with sane defaults. When we wire moox Scope for example all packages that support scopes are prepared with field, config and integration code. A class_exists prevents errors when moox Scope is not installed.
No Coding
moox Fields (or the name we invent later) is a good example for no-code. Create ... to be contiued.
Maintainablity
... tbc ... use moox Core base classes (later maybe just traits)
In prior to having perfect docs, an MCP server, I collect some dev-rules here:
Modularity
Everything goes into packages. Many packages may ship with just one single entity. This cares for SRP. Entities that ship with relations ... always polymorphic.
Loose Coupling
Packages should mostly not be required, but configurable. Like with Relations, Taxonomies as array that allows multiple classes or like User (author model) and Scope by a single class assignement. In rare cases where config seems not useful, we use class_exists solely.
Sane Defaults
When things are configurable, those should be preconfigured with sane defaults. When we wire moox Scope for example all packages that support scopes are prepared with field, config and integration code. A class_exists prevents errors when moox Scope is not installed.
No Coding
moox Fields (or the name we invent later) is a good example for no-code. Create ... to be contiued.
Maintainablity
... tbc ... use moox Core base classes (later maybe just traits)