Sounds like it would be a good idea to get the CI process to check for usage of debugging functions. I'm sure it would be possible to write a phpstan rule to forbid var_dump. Maybe another solution would be to make them noops on production.

You can use phpcs <https://github.com/squizlabs/PHP_CodeSniffer/blob/master/src...> to easily do this.

> Maybe another solution would be to make them noops on production.

There is a way, but it's dangerous: https://www.php.net/manual/en/function.runkit7-function-rede...

Slightly off topic, but when I was debugging a release pipeline in Azure Devops I discovered that they do a surprisingly good job of keeping secret values out of the logs: I was trying to dump a connection string with inline powershell but found that it was always masked with **. I had to resort to base64 encode the connection string to get it to print. I suppose they scan the output buffer and compare it with known secrets before printing.

Ah, stuff like this always reminds me the famous (or rather infamous?) hunter2 (or rather *******?) conversation:

http://bash.org/?244321

From TFA:

    > an interface, which cannot implement or inherit from other interfaces

An interface in PHP most definitely can extend multiple other interfaces.

> This subtle nuance (value equivalency versus object equivalency) can cause problems, particularly if variables are passed by reference to any other functions in your codebase.

Value objects may be great for leveraging the type system to help you write better code by e.g. having only one place for validation. But why should you pass scalar variables by reference? That makes it really hard to reason about what functions and methods do.

There’s an RFC in discussion to add a Sensitive Value attribute that would prevent values from being output in the logs. It won’t stop serialization of the values though.