Intro
We have all been there - for whatever reason your debugger is not working (or you're being lazy) so you decide to use var_dump('here');exit;
or something similar during development to work out what is going on with your code.
You finally fix the issue, commit your code and push it up and then the code reviewer fails it because of your var_dump()
being left in. Or worse - they miss it and suddenly strange messages (like "got here") start appearing on your test environment!
Then, having already wasted the time of your code reviewer and potentially other colleagues, you have to waste your own time and energy removing it and updating your PR. If only there was something you could do to prevent this...
Good news, there is!
Don't use var_dump!
The best thing you can do is avoid using var_dump()
at all. If you're using TDD and/or BDD you likely will very rarely need any sort of debugging. In any case you should get your debugger working just in case. But this is beyond the scope of this article...
Let your IDE spot your var_dump for you
If you're a PHP developer, you may well using PHPStorm or another Jetbrains IDE - so get the PHP Inspections plugin and you will make your life waaay easier! It also has an inspection built in that underlines any var_dump()
calls in red and gives you a nice warning message.
Add a pre-commit hook to save you from yourself
What's a git hook?
The concept of git hooks is explained elsewhere but basically it's an event-based script runner. So you can tell git to run a particular shell script when a particular thing happens.
The code
In this case "pre-commit" means "before a commit is saved" and the script that can be run is one that I use for my PHP projects. The part of code in particular that checks for var_dump()
s is:
# Prevent committing of "var_dump"s in code
VAR=$(git diff --cached | grep -w "var_dump")
if [ ! -z "$VAR" ]; then
echo "Detected a var_dump in one of your files. Aborting commit"
echo "$VAR"
exit 1
fi
You can download the full pre-commit hook from GitHub.
'Hooking' it up...
By default, git hooks are run from inside the .git/hooks
directory - but you can't actually commit them to your repository from there. This is why I prefer to add them in a custom folder and tell Git where they live...
To add this (or any other hook) to your repository, you need to add the file itself and ensure it's executable, then tell git about the file (where it exists, and that it should run it):
- Create a folder inside your git repository called
bin/git-hooks
(or whatever you want to call it). - Add your file to that folder (named
pre-commit
- no extension) - Ensure your file is in executable mode (run
chmod +x
on your file) - Edit your git repository's configuration file:
git config -e
- Set
core.hooksPath
to./bin/git-hooks/
- like the following (there may be other keys/values in there of course...)
[core]
hooksPath = ./bin/git-hooks/
That's about it!
What about you? Got some other really cool git hooks you're using? Why not share them in the comments!
Top comments (3)
I agree with not using
var_dump()
. Every PHP developer should be using XDebug as an interactive debugger. Works great both on PHPStorm and VS Code.Although working with Laravel I often resort to using
dump()
anddd()
since they provide a lot of useful information fast. Having a good unit test coverage will also reveal secret dumps since they get printed on the standard output.While a nice idea and recommended, the safest way is to have a check in the CI pipeline for this and other functions, like
die;
.Definitely agree - can’t hurt to shorten the feedback loop even more though :)