DEV Community

Dan Silcox
Dan Silcox

Posted on

PHP - 'dump' those debug statements!

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
Enter fullscreen mode Exit fullscreen mode

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/
Enter fullscreen mode Exit fullscreen mode

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)

Collapse
 
nikoheikkila profile image
Niko Heikkilä

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() and dd() 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.

Collapse
 
exadra37 profile image
Paulo Renato

Add a pre-commit hook to save you from yourself

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;.

Collapse
 
dansilcox profile image
Dan Silcox

Definitely agree - can’t hurt to shorten the feedback loop even more though :)