Blog

A common pattern when testing Laravel validation looks like this:

Tests that read or write files can be really annoying. I’ll admit it, in the past I’ve skipped a few. I just hate having to think about seeding the files, cleaning them up after, and don’t get me started on the pollution left over when a test crashes before it can tear down.

Here’s a Livewire checkout component that looks completely fine:

I’ve taken the stance before against pulling code into a method just to make a longer one look shorter. So you’d think my AppServiceProvider would be a straight line of code. It isn’t.

We’ve all been there: building out something and the method is getting to about 50 lines. It feels messy and off. So you do what everyone has learned: extract methods like Martin Fowler says to do.

Our apps do a lot of writing. Emails, notifications, invoices, dashboards. All of that copy has to follow the same style guide as anything else we publish.

Say your style guide follows AP style, which spells out the numbers zero through nine and uses digits for 10 and up. It is a simple enough rule that most of us just write our own tedious conditional for it, never thinking to check if the framework already handles it.

Code and comments belong to the whole team. Once something lands in the codebase, the next reader tends to treat it as established fact, even when it started as one person’s hedge or guess.

Sometimes that is exactly the problem. Now and then I write a comment that is not settled truth. Maybe I am unsure, maybe it is a personal opinion, maybe it is only true for today.

Most of our GitHub workflows pull in actions/checkout and never touch its inputs. That is fine most of the time, but one input matters a lot for security. It is persist-credentials.

A composer script is often named after the underlying tool, like phpstan, because that is the binary the script calls. But what if you or the team always refers to the tool as larastan because that is the plugin or package providing most of the functionality for your project? “Did Larastan catch that?” asks another programmer, even though composer.json says phpstan.

Joel mentioned this convention in Why would I leave an unused variable in my test?, where he leaves “noise” records assigned to unused variables for readability. If you were wondering why bother with the noise records at all, here is the demonstration.