Primum nil nocere in PHP: First, Do No Harm

Doctors have a saying: primum nil nocere — “first, do no harm.” I first heard it in a medical context, but it stuck with me. Could the same principle apply to programming? Absolutely — especially when working with legacy code.

If you work on legacy applications, you quickly learn one truth: every change can have unexpected side effects. The architecture is rigid, the design outdated, and the smallest tweak might break something miles away in the codebase. Still, we all want to make things better today than they were yesterday.

That’s why I wrote a pre-commit Git hook to apply the do no harm principle to my daily development. The idea is simple:

• The whole codebase is under Git.
• Every commit should meet the current coding standard (PSR-12 in my case).
• Running PHP_CodeSniffer on the entire legacy project is slow and noisy.
• So instead, I only check the lines I’ve actually changed.

If my changes violate the standard, the commit fails until I fix them. Over time, this improves the codebase without drowning me in thousands of old warnings.

Sometimes, I can’t fix a file immediately because of other existing violations. In that case, the hook can just warn instead of blocking the commit, letting me decide what to do. You can also extend the script with your own rules — the setup is entirely yours.

Each time you commit, you’re leaving the codebase a little cleaner, a little better. It’s like a doctor treating a patient: you’re not curing every illness at once, but you’re making sure you don’t make things worse.

The script is in my repository — take it, use it, adapt it. And remember: even in PHP, first, do no harm.

Comments

[david duymelinck]

I'm glad to see a non AI solution for this!

[István Döbrentei]

The idea comes from my own experience and I tested it as well. Since I’m not a Bash expert, I asked for some assistance with the final version of the script, but it wasn’t just copy-paste — I worked through it carefully. The ruleset is only an example; it can vary depending on the project and expectations. You can always add more rules as needed.