Coding styleguide
Coding style choices directly affect how easy a project is to navigate. The styleguide of a project should be seen as a guide, not a rulebook. The purpose of having a styleguide is not to enforce strict rules, but to enhance consistency throughout a project.
You do not have to follow it exactly, but it is worth reading because the framework is designed with those ideas in mind:
Whatever conventions you choose, consistency matters more than novelty.
Naming conventions in WebEngine
Path mapping
Page files should map clearly to URLs. // TODO: Expand what this means.
That is one of the reasons WebEngine uses file-based routing so heavily: the path itself becomes part of the documentation.
// TODO: Explain the preference of how page files and URIs should be named (lower-case hyphenated files in the page directory, for URIs).
Classes
Application classes should map clearly to namespaces.
Database files
Query files should be named similarly to URIs. // TODO: Is this even true?
Page logic style
Keep page logic small and readable. Use explicit action names for do_* handlers. Keep the request flow easy to scan.
If a page file starts to feel like the centre of the whole application, that is usually a sign that behaviour should move into application classes.
Application class style
Application classes work best when their responsibilities are cohesive and their dependencies are clear. Prefer small classes that own one kind of behaviour over broad “everything” classes that know too much.
Framework-light classes are also easier to test and easier to move if the project changes direction later. // TODO: Expand what this means.
HTML and template style
Write semantic HTML and use binding attributes deliberately. The page view should still make sense to a reader who has not yet opened the matching PHP file.
Running, testing, and deploying applications requires a PHP environment setup.