Originally published on decentphp.dev — part of the Writing decent PHP course. View this lesson on the original site.

How this course is structured

This course is designed as a progression, not a random list of topics.
Each chapter gives you one layer of practical judgement, so by the end you can write PHP that is readable, maintainable, and safer to change.

mindmap
  root((Writing decent PHP))
    1 Quality bar
    2 Naming
    3 One job
    4 Nesting
    5 Data shaping
    6 Boundaries
    7 Folders
    8 Errors
    9 Change
    10 SOLID
    11 SRP
    12 DI
    13 Composition
    14 Profiling
    15 Docs and ADRs
    16 Refactors
    17 Release and handover

Chapter-by-chapter goals

What each current chapter is trying to achieve

1. What decent PHP means after fundamentals: set the quality bar beyond "it works".
2. Naming variables, functions, classes, and files well: make intent obvious at first read.
3. Functions that do one job well: reduce side effects and keep behaviour focused.
4. Reducing nesting and making code easier to scan: improve flow with guard clauses and flatter control paths.
5. Data shaping with arrays and simple value objects: keep data contracts predictable and explicit.
6. Separating input, work, and output: define clearer boundaries between edge handling and core logic.
7. Organising files, folders, and small modules: improve navigation and reduce change surface.
8. Error handling choices: exceptions, return values, and boundaries: choose failure strategies intentionally.
9. Writing code that is easy to change: optimise for maintainability under ongoing product work.
10. Intro to SOLID: why these principles exist: understand why these principles were introduced in the first place.
11. Single responsibility and cohesion in normal PHP code: keep related behaviour together and responsibilities clear.
12. Dependency inversion and dependency injection without a framework: reduce coupling with explicit dependencies.
13. Composition over inheritance in app code: prefer flexible composition when behaviour needs to vary.
14. Performance profiling without guessing: use measurement before optimisation.
15. Documentation, ADRs, and handover: preserve context so teams can maintain code safely.
16. Maintainability and refactors: improve legacy areas incrementally without breaking behaviour.
17. Release operations and team handover: make deployment and ownership transitions safer and more repeatable.

What this means for you

If a lesson feels repetitive, that is deliberate.
The same core ideas (clarity, trade-offs, verification, and maintainability) are revisited in different contexts so they become habits, not just theory.

From Writing decent PHP — What decent PHP looks like