This month, we speak to Rokas Šleinius about Kint, a drop-in replacement for PHP’s native debugging functions.
WPM: Who’s behind Kint?
Šleinius: Kint has been a single-person project, but over the recent years I’ve had some valuable contribution thanks to the popularity of Github and the power of open source in general.
Why did you decide to start it?
I am constantly looking for ways to improve my workflow – and I realised this is the kind of tool that would help out in a HUGE way. At the time I began Kint, the only alternative was the awfully buggy and already-then-abandoned Krumo. Please don’t even link to it, I’d hate to give it even more popularity.
Kint became a huge part of my development cycle, dumping newly created variables, debugging condition outcomes, etc, and eventually it became too good to withhold to myself 🙂 Kint is much more than a debugging tool. I use it all the time and sincerely have no idea how others can develop effectively without it.
What’s wrong with PHP’s native debugging tools?
Kint to var_dump() is what a full-fledged IDE is to MS Notepad. Both do the job, however neither notepad nor var_dump() are tailored to do real world tasks. They are bare, generic necessities to resort to when nothing better is available.
The problem with var_dump(), debug_backtrace() and the like is that they are terribly awkward to use and – much more importantly – the information they generate is not easy for a human to comprehend.
How does Kint compare to Xdebug?
Xdebug adds a couple of features to vanilla var_dump() to make it a little more bearable to use but not more.
Kint, on the other hand, has dozens upon dozens of essential features I can’t imagine coding without. It’s a tool written from scratch by a developer for developers – not a layer on top of some other sub-standard tool. It’s been in the works for over three years and has become really functional and a pleasure to use.
You can read about (most of) the myriad of features in the project page (http://raveren.github.io/kint/), and the best part is, it’s dead-simple to begin working with and you’ll discover the advanced usage gradually if you’re interested.
Is manual debugging any substitute for unit testing?
These are two different areas and both are critical. You definitely need test coverage for your code as much as you need a proper toolset to fix bugs when tests don’t pass.
How can people get involved in the project, and what tasks are there to help out with?
I really appreciate issues and pull requests both, but I’m not in need of any development help currently. There’s an active WIP branch (https://github.com/raveren/kint/tree/1.0.0-wip) at the time of writing and new features are constantly being released. Until I reach the 1.0 version, the whole codebase can change radically and I will release contribution guidelines and tutorials only when I’m comfortable with every aspect of the Kint codebase.
Where do you hope to see the project in a year’s time?
Kint is not the only project of mine that I want to release. I am passively preparing to opensource my error-handling toolset, which integrates Kint heavily and is way better than everything I’ve tried so far. I’m hoping to package and release it in the near future, so there’s that.
I am hoping that one day, Kint, plus the to-be-released error handler will be accepted as de facto debugging tools for PHP and be included in 3rd party frameworks by default.