When you're learning to write custom rules for PHPStan or Rector, you'll have to learn more about the PHP programming language as well. To be more precise, about the way the interpreter parses PHP code. The result of parsing PHP code is a tree of nodes which represents the structure of the code, e.g. you'll have a Class definition node, a Method definition node, and within those method Statement nodes, and so on. Each node can be checked for errors (with PHPStan), or automatically refactored in some way (with Rector).

The tree of nodes is called Abstract Syntax Tree, and a successful PHPStan or Rector rule starts with selecting the right nodes from the tree and "subscribing" your rule to these nodes. A common approach for this is to start var_dump-ing or echo-ing nodes inside your new rule, but I've found this to be quite tedious. Which is why I've created a simple command-line tool that lets you inspect the nodes of any given PHP file.

Having discussed different aspects of simplicity in programming solutions, let's start with the first topic that should be scrutinized regarding their simplicity: persisting model objects. As you may know, we have competing solutions which fall into two categories: they will follow either the Active Record (AR) or the Data Mapper pattern (DM) (as described in Martin Fowler's "Patterns of Enterprise Application Architecture", abbrev. PoEAA).

"As I'm becoming a more experienced programmer, I tend to prefer simple solutions." Or something similar. As is the case with many programming-related quotes, this is somewhat of a blanket statement because who doesn't prefer simple solutions? To make it a powerful statement again, you'd have to explain what a simple solution is, and how you distinguish it from not-so-simple solutions. So the million-dollar question is "What is a simple solution?", and I'll answer it now.

Just kidding. But I do have some ideas about this.