best practices

All my posts about best practices.

Don’t clone your php objects, DeepCopy them

dcsg.me

Daniel Gomes, a developer at Teamleader, explains a potential problem when cloning object in PHP.

As you know, PHP has a well-known clone keyword that shallow copy all of the object’s properties. So under the hood what it does is to create a new Object with the exact same values of that object properties – unless you change its behavior by implementing the clone() function in your class.

Read more [dcsg.me]

Reusing domain code

matthiasnoback.nl

Here's another excellent post by Matthias Noback.

Reuse-in-the-small is definitely possible. Reuse-in-the-large is deemed to be impossible, because no two problems/projects are alike, but practice proves otherwise. There are reusable components covering entire subdomains, which are nonetheless quite successful. The chance of success is bigger if such a reusable component is used to cover for a generic subdomain. Using an off-the-shelf solution in such a case helps you save development effort which can instead be redirected to the core domain.

Read more [matthiasnoback.nl]

Join 9,500+ smart developers

Get my monthly newsletter with what I learn from running Spatie, building Oh Dear, and maintaining 300+ open source packages. Practical takes on Laravel, PHP, and AI that you can actually use.

No spam. Unsubscribe anytime. You can also follow me on X.

Mo' models mo' problems

sebastiandedeyne.com

Here's another awesome blogpost by my collegue Seb. In this one he explains why you should and how you can create an explicit Vue component API.

When refactoring your UI to components, always keep in mind that props and events are your components public API. Just like when you're modelling your application's domain, try to keep things explicit. Props and events should be enough to tell the outside world everything it needs to know about a component's behavior.

Read more [sebastiandedeyne.com]

Why your form only needs one name field

uxmovement.com

Here are some good reasons why you shouldn't use a first name and last name field.

The structure of a name is not the same across cultures. Users who visit your site will consist of a broad range of people from different countries. Your name field should be culturally inclusive so that no one struggles to fill out your form. With most things in life two is better than one. But when it comes to name fields one is better than two.

Read more [uxmovement.com]

The Everybody Poops Rule

rosstuck.com

Ross Tuck makes the case that not all code is equal.

Most teams follow the Broken Window Theory, fearing even a single tradeoff starts the slide down a slippery slope. This can reduce discussion (read: dissension) in the short term but leads to arbitrary compliance or worse. ... Deciding on a level of quality isn’t like deciding on a coding standard, you can’t have an off-the-shelf-always-okay answer. Quality is the place to have nuanced discussions.

Read more [rosstuck.com]

Objects should be constructed in one go

matthiasnoback.nl

In another cool blogpost, Matthias Noback explains a few best practices around newing up objects, illustrated with some great examples.

Consider the following rule: "When you create an object, it should be complete, consistent and valid in one go." It is derived from the more general principle that it should not be possible for an object to exist in an inconsistent state. I think this is a very important rule, one that will gradually lead everyone from the swamps of those dreaded "anemic" domain models. However, the question still remains: what does all of this mean?

Read more [matthiasnoback.nl]

Using EditorConfig

Frederick Vanbrabant recorded a new cool video, this time on EditorConfig.

EditorConfig helps developers define and maintain consistent coding styles between different editors and IDEs. The EditorConfig project consists of a file format for defining coding styles and a collection of text editor plugins that enable editors to read the file format and adhere to defined styles. EditorConfig files are easily readable and they work nicely with version control systems.

Read more

The road to dependecy injection

matthiasnoback.nl

Mattias Noback shares how you can migrate a code base that fetches its dependencies using static method calls to code that uses dependency injection.

I've worked with several code bases that were littered with calls to Zend_Registry::get(), sfContext::getInstance(), etc. to fetch a dependency when needed. I'm a little afraid to mention façades here, but they also belong in this list. The point of this article is not to bash a certain framework (they are all lovely), but to show how to get rid of these "centralized dependency managers" when you need to.

Read more [matthiasnoback.nl]

The art of the error message

thestyleofelements.org

Marina Posniak, UX writer at Spotify, shares some great tips on how to write error messages well.

To start, ask yourself if you even need the error message. Before writing anything, consider if there’s a way to redesign the experience so there’s no error at all. Is there a way to just make it work? (Really, the best error message is no error message.) But if you do need it, think carefully about the message. When things go wrong and the app “fails,” say something useful. The message should help the user solve the problem and move on.

Read more [thestyleofelements.org]

Keeping your Laravel applications DRY with single action classes

medium.com

Rémi Collin shares a cool approach on where to place code that doesn't really belong in a controller. He creates small, reusable, testable, decoratable classes, called Actions.

Using this approach can seems a lot of classes at first. And, of course the user registration is a simple example aimed to keep the reading short and clear. Real value starts to become clear once the complexity starts growing, because you know your code is in one place, and the boundaries are clearly defined.

Read more [medium.com]

Practicing symmetry

In a new video Jason McCreary, the creator of the wonderful Laravel Shift, demonstrates a few good tips to clean up code. In the video below Jason uses a code snippet taken from my side project Oh Dear!

If you're interested in more tips from Jason be sure to check out his upcoming BaseCode field guide.

Meanwhile I've cleaned up (and deployed) the code in the actual app. This is what I ended up with:

class Check
{
    public function needsToRun(): bool
    {
      if (!$this->belongsToTeamOnActiveSubscriptionOrOnGenericTrial()) {
          return false;
      }
			
      if ($this->disabled()) {
          return false;
      }
			
      if ($this->alreadyRunningOrScheduled()) {
          return false;
      }
			
      if ($this->didNotRunBefore()) {
          return true;
      }
			
      if ($this->checkType()->is(CheckType::UPTIME) && $this->latestRun()->failed()) {
          return true;
      }
			
      if ($this->previousRunCrashed()) {
          return true;
      }
      return $this->latestRun()->endedMoreThanMinutesAgo($this->checkType()->minutesBetweenRuns());
    }
		
    protected function checkType(): CheckType
    {
        return new CheckType($this->type);
    }  
}
use MyCLabs\Enum\Enum;

class CheckType extends Enum
{
    const UPTIME = 'uptime';
    const BROKEN_LINKS = 'broken_links';
    const MIXED_CONTENT = 'mixed_content';
    const CERTIFICATE_HEALTH = 'certificate_health';
    const CERTIFICATE_TRANSPARENCY = 'certificate_transparency';
    public function minutesBetweenRuns(): int
    {
        if ($this->getValue() === static::MIXED_CONTENT) {
            return 60 * 12;
        }
				
        if ($this->getValue() === static::BROKEN_LINKS) {
            return 60 * 12;
        }
				
        if ($this->getValue() === static::CERTIFICATE_HEALTH) {
            return 5;
        }
				
        if ($this->getValue() === static::UPTIME) {
            return 3;
        }
				
        throw new Exception("Minutes between runs not specified for type `{$this->getValue()}`");
    }
    public function is(string $type): bool
    {
        return $type === $this->getValue();
    }
}

Read more

Tidy up your tests with class-based model factories

John Bonaccorsi, a developer from Tighten, wrote some good ways of structuring model factories in a Laravel app.

Thanks to class-based model factories, our test setup went from being a bloated mess to simple and succinct. The optional fluent methods give us flexibility and make it obvious when we are intentionally changing our world. Should you read this blog post and immediately go and update all of your model factories to be class-based instead? Of course not! But if you begin to notice your tests feeling top heavy, class-based model factories may be the tool to reach for.

https://tighten.co/blog/tidy-up-your-tests-with-class-based-model-factories

Read more

A good issue

Sebastian De Deyne, package creator and JavaScript wizard at Spatie, gives some good tips on how to report an issue well.

Maintaining a number of open source projects comes with a number of issues. Reporting a good issue will result in a more engaged approach from project maintainers. Don't forget: there's a human behind every project.

https://sebastiandedeyne.com/posts/2018/a-good-issue

Read more

Make a clear distinction between different layers of validation

In an older, but still very interesting article, Mattias Verraes has some interesting thoughts on form, command and model validation.

Many of the frameworks I’ve worked with, promise to separate responsibilities with MVC. In practice, they end up coupling everything to everything. The forms are coupled to the models, and there’s a grand unified validation layer. This may be convenient at first, but it breaks down for larger systems, and creates headaches when having to support multiple clients. My approach is to clearly separate the validation for the form itself, from the Command validation and the model validation.

http://verraes.net/2015/02/form-command-model-validation/

Read more

Combing legacy code string by string

Mattias Noback gives some good tips for refactoring legacy code.

"Combing" legacy code by untangling the strings is a good way to improve it and take back control over it. In existing legacy code, you should stop (re)using existing methods, making them ever more generic. Instead, you create new methods, and copy code from existing ones, allowing you to simplify this copied code and end up with a manageable class.

https://matthiasnoback.nl/2018/04/combing-legacy-code-string-by-string/

Read more

Separate Interactive Test Suites

If you find yourself having a bunch of slow tests that don't need to execute every time you run the tests, take a look at PHPUnit's defaultTestSuite setting. TJ Miller explains it in a blog post he wrote last year.

To avoid running the interactive test suite with the rest of my tests, manually or via a CI job, I had to explicitly include all the other suites using phpunit --testsuite Api,Feature,Unit. This felt a bit grim and I would rather exclude just that one suite. So I did some digging and found the defaultTestSuite configuration for phpunit.

https://medium.com/@sixlive/separate-interactive-test-suites-f6fd59316ec2

Read more

Nothing is Something

Here's a video of a great talk by Sandi Metz she gave at RailConf 2015.

Our code is full of hidden assumptions, things that seem like nothing, secrets that we did not name and thus cannot see. These secrets represent missing concepts and this talk shows you how to expose those concepts with code that is easy to understand, change and extend. Being explicit about hidden ideas makes your code simpler, your apps clearer and your life better. Even very small ideas matter. Everything, even nothing, is something.

Read more