Learn from your fellow PHP developers with our PHP blogs, or help share the knowledge you've gained by writing your own.
var_dump()
, which is obviously not the best way to do it. If you see the code for the first time, if you work with legacy code - step-by-step interactive debugging is the way to go. Sometimes it can save you hours of old school var_dumping.watch phpunit /path/to/test
while developing: this way the test is run every 2 seconds, you switch to the terminal whenever you want to see the latest results and that's it. However, there are certain advantages in running tests from the IDE. First, it's super-handy to launch a test method, test class or a whole folder with tests, just by pressing a hotkey. Second, the test results appear right there, in PHPStorm, with failures and their stack traces, every entry clickable and takes you directly to the file:line where a nasty thing happened. I also find the ability to run a debugger for a unit test, extremely attractive. Test fails, you click on a trace entry, get to a problematic line, place a break point, re-run the test in debug mode - and there you go.$HOME/projects/cool-project
, but inside a docker or on a remote host it might be located at /app
or /var/www
, then you have to let PHPStorm know about this.Debugging is like being the detective in a crime movie where you are also the murderer. Filipe Fortes a.k.a. @fortes
$cache = app("cache");
app("cache"")
and expect a Cache\Repository
instance as result. If I pass the result of this call to a function that requires a Cache\Repository
as parameter, I will probably have a code inspection warning from IDE. Moreover, if I want proper autocompletion, I will have to add additional comment:
$cache = app("cache");
namespace App;
class MyApp extends Application
{
public function cacheRepository(): Repository
{
return $this->make(Repository::class);
}
}
TypeError
in case of a misconfiguration, and I have a type-hint which allows the IDE to recognize the return value. Bye-bye nasty comment lines and IDE warnings! I make a method per service, with type-hints, like dbConnection()
or viewFactory()
- works really well for me!bootstrap/app.php
, should reside in that custom class:namespace App;
class MyApp extends Application
{
public function __construct()
{
define('LARAVEL_START', microtime(true));
define("APP_ROOT", realpath(__DIR__ . "/../"));
parent::__construct(APP_ROOT);
$this->setUp();
}
private function setUp()
{
$this->singleton(
Contracts\Http\Kernel::class,
\App\Http\Kernel::class
);
}
}
bootstrap/app.php
becomes just this:return new \App\MyApp;
app()
function will also return an instance of MyApp from now on. However, it's @phpdoc says it returns \Illuminate\Foundation\Application
, so for better clarity, I also added my own accessor method:namespace App;
class MyApp extends Application
{
public static function app(): self
{
$ret = parent::getInstance();
return $ret;
}
}
MyApp::app()
. The IDE wil be aware of the return type due to the type-hint, so I get everything I want for clean and clear development.Zephir, an open source, high-level language designed to ease the creation and
$variables
. You only can create object oriented extensions, and all the classes written in Zephir must be namespaced. A different and stricter type system exists in Zephir, which allows for transpiling the code you write, into a real C extension.class CreateProductCommand {
public $name;
public $price;
}
class GetProductQuery {
public $productId;
}
class CreateProductCommandHandler {
public function handle(CreateProductCommand $command) {
}
}
class GetProductQueryHandler {
public function handle(GetProductQuery $query) {
}
}
class Product {
public $name;
public $price;
}
class ProductView {
public $name;
public $price;
}
$command = new CreateProductCommand();
$command->name = "Example Product";
$command->price = 99.99;
$handler = new CreateProductCommandHandler();
$handler->handle($command);
$query = new GetProductQuery();
$query->productId = 123;
$handler = new GetProductQueryHandler();
$product = $handler->handle($query);