ALWAYS use strict comparison (=== and !==). If needed, cast things go the correct type before comparing. Better than weird == results

Also consider enabling strict types in your code. This will prevent passing variables of wrong data types to functions https://t.co/C0is2rghbs

In the example below, the value reaches the middleware, where you can do some stuff, and then is REMOVED from the route parameters before being passed to the action. https://t.co/3TNUnucmz3

Such as, checking if an Order is locked inside an OrderProduct.

OrderProducts cannot be added to/changed in a locked order. https://t.co/4v8iIkebPk

Your controllers should be simple. They should say things like "create invoice for order". They shouldn't be concerned with the details of how your database is structured.

Leave that to the model. https://t.co/1w1s2sbwkO

What you may not realize is that the when() method also accepts a second callback for the falsy case. This is really helpful for setting a sort default. 🤩 https://t.co/11eni5DW1Z

Using some "macro" philosophy for structuring your code, like hexagonal architecture or DDD won't save you.

A clean codebase is the result of constant good decisions at the micro level.

Instead of writing controller actions like PostController@index, use the callable array syntax [PostController::class, 'index'].

You will be able to navigate to the class by clicking PostController. https://t.co/h2UF1te3E3

Rather than passing a huge amount of arguments in a specific order, consider creating an object with properties to store this data.

Bonus points if you can find that some behavior can be moved into to this object. https://t.co/C1FSrjYWLP

Rather than thinking "what can this object do", think about "what can be done with this object". Exceptions apply, such as with action classes, but this is a good rule of thumb.

https://t.co/LScInA8ToE https://t.co/lLm5SaWk2m

For example, use $model->is($anotherModel) to check if they refer to the same row. https://t.co/kBquNQYPgA

This is largely a matter of personal preference, but calling a global function instead of having to import a class and statically call a method feels nicer to me.

Bonus points for session('key') syntax. https://t.co/AbMzJl4Puz

Create a class if it's used on multiple places or way too complex. https://t.co/nslCQb8pDh

Consider offloading some logic from controllers to events. For example, when creating models.

The benefit is that creating these models will work the same everywhere (controllers, jobs, ...) and the controller has one less worry about the details of the DB schema https://t.co/6zJaMPScBk

Similar to single-use traits.

This tactic is great when you have a very long template and you want to make it more manageable.

There's nothing wrong with @including headers and footers in layouts, or things like complex forms in page views.

Great for debugging/tweaking the design. https://t.co/bdB22XLnHz

You can also create objects with fluent APIs. Gradually add data by with separate calls, and only require the absolute minimum in the constructor.

Each method will return $this, so you can stop at any call. https://t.co/826OBHPEAX

They're a great place to hide complex validation logic.

But beware of exactly that — hiding things. When your validation logic is simple, there's nothing wrong with doing it in the controller. Moving it to a form request makes it less explicit https://t.co/RwzDxANxXj

Custom collections got you sorted. Love these methods. https://t.co/1sehVNNDug

The code will be cleaner & more readable and you will see understandable exceptions if something goes wrong. No half-passing edge cases. https://t.co/zarUdjftUi

Creating custom collections can be a great way to achieve more expressive syntax. Consider this example with order totals. https://t.co/vFBtUFlR7n

$domain->refresh(); to refresh its attributes

$tenant->load('primary_domain'); to update the primary_domain relationship on the $tenant instance https://t.co/FdzT5rilEr

Adding methods to classes where they belong is cleaner than creating action classes for everything, but it can make the classes grow big

Consider using traits. They're meant primarily for code reuse, but there's nothing wrong with single-use traits https://t.co/dWWLNWuOoS

You can tell the app what response to return when a specific exception is encountered.

This is the simplest example. There's many more use cases. https://t.co/diMoktScI3

Install extensions, write annotations, use typehints. Your IDE will help you with getting your code working correctly, which lets you spend more energy on writing code that's also readable. https://t.co/xNMR2UHed7

Extremely handy when you have multiple admin panels in a single app. https://t.co/3HvDb1Ae3N

Sometimes people put helpers into a class.

Beware, it can get messy. This is a class with only static methods used as helper functions. It's usually better to put these methods into classes with related logic or just keep them as global functions. https://t.co/iIcyReIW9N

The opposite of the previous tip. Sometimes the value comes from a complex call and as such, creating a variable improves readability & removes the need for a comment.

Remember that context matters & your end goal is readability https://t.co/hwFni2X6zA

Too much nesting & else statements tend to make code harder to read. https://t.co/PGueS91cgD

If some method is too long or complex, and it's hard to understand what exactly is happening, split the logic into multiple methods. https://t.co/ljFm6RFk8i

Opening an array with [ and indenting the values tends to work well. Same with long function parameter values.

Other good places to split lines are chained calls and closures. https://t.co/bnTL2I0Bxa

Left: double nesting Right: arrow function https://t.co/6vxwuttW4G

One of them is examining sent emails ✉️

You usually don't need a service like Mailtrap. Just use the log mail driver and install Telescope.

(image stolen from the internet) https://t.co/odX4ZHzHE3

If you validate some resource's attributes on multiple places, you definitely want to centralize these validation rules, so that you don't change them in one place but forget about the other places.

https://t.co/qI1Q0HUEyK

The $loop variable.

It greatly complements Tailwind-styled tables.

Striped tables done easily 🎉 https://t.co/prm735AEuN

$model->getOriginal()

in Eloquent event listeners can be very useful.

One such use case is checking whether an order is locked. If it is, the only write action we permit is unlocking it. Only then can changes be made. https://t.co/rDD1ziOapj

If you want to retrieve some data from a model, create an accessor.

Keep methods for things that change the model in some way. https://t.co/3IpmbDuNF9

Don't turn all arrays into collections just because Laravel offers them, but DO turn arrays into collections when you can make use of collection syntax to clean up your code. https://t.co/Jd8O3QFrP8

PHP has many great operators that can replace ugly if checks. Memorize them. https://t.co/pGLyyNtwpj

If you have a complex route action, consider moving it to a separate controller.

For OrderController::create, you'd create CreateOrderController.

Another solution is to move that logic to an action class — do what works best in your case. https://t.co/Rn6lFnhkVH

Functional code can both clean things up and make them impossible to understand. Refactor common loops into functional calls, but don't write stupidly complex reduce()s just to avoid writing a loop. There's a use case for both. https://t.co/1xVD2qwtkw

Many people will disagree with this, because they do it. But it makes no sense.

There's no point in using docblocks when they don't give any extra information. If the typehint is enough, don't add a docblock.

That's just noise. https://t.co/Q2O6Kp0jzN

Let's expand on the previous example. Sometimes, creating a class for a single action can clean things up.

Models should encapsulate the business logic related to them, but they shouldn't be too big. https://t.co/Mll37AAh5o

Above I said that moving business logic to action/service classes is good. But context matters

Here's code design advice from a popular "Laravel best practices" repo. There's absolutely no reason to put a 3-line check into a class. That's just overengineered https://t.co/zOtKmaVtMu

If you repeat some code a lot, consider if extracting it to a helper function would make the code cleaner. https://t.co/2e4TtoVn9N

You can use ddd() instead of dd().

I tend to forget about this one, but it's super useful. https://t.co/hjVNOeLTRI

This ties the previous tweet with the other tips here. OOP exists to make your code more readable, use it. Don't just write 400 line long procedural code in controller actions.

Here's code from my first Laravel project 😬 https://t.co/2DeGX148Wh

You can store things like "results per page" in config files. Don't add them to the app config file though. Create your own. In my e-commerce project, I use config/shop.php. https://t.co/kXkte9Ysrv

Rather than writing complex where() clauses, create query scopes with expressive names.

This will make your e.g. controllers have to know less about the database structure and your code will be cleaner. https://t.co/mqxugYM4oG

Don't think that long variable/method names are wrong. They're not. They're expressive.

Better to call a longer method than a short one and check the docblock to understand what it does

Same with variables. Don't use nonsense 3-letters abbreviations https://t.co/a23I1L7TtW

I developed this habit when I was building a lot of data conversion scripts in Python, but it's 100% applicable in PHP as well. https://t.co/fGnbAwoj26

You can make your Blade templates more expressive by creating custom directives. For example, rather than checking if the user has the admin role, you could use @admin. https://t.co/FY5CMi4gVP

And so much more. https://t.co/EqVABRXKQJ

You DON'T have to go raw SQL when you hit a performance issue with Eloquent. There's so many "secret" techniques.

Example: You can create scopes to add specific selects to your queries. https://t.co/YrIWlKf2K7

Very useful if you want to tag jobs with things like the user/tenant id. https://t.co/cpg1Zp5BPu

Sometimes you may have multiple classes with the same name. Rather than importing them with an alias, import the namespaces. https://t.co/O14vx38oan

Example: Default value set on creation. https://t.co/eXVC8WR0xV

I didn't know about this for so long.

Instead of: $table->unsignedBigInteger('user_id'); $table->foreign('user_id')->references('id')->on('users');

You do: $table->foreignId('user_id')->constrained();

Not recommended in most cases, but interesting.

(image stolen from the internet) https://t.co/8kKmRUYi8e

It's IMO better to use static properties and have "self-contained" behavior & configuration. Than to have a billion config keys. Especially when building large packages.

Makes the package more extensible, by consisting of atomic parts https://t.co/tyucZmkmsz

Know the difference between static/instance methods & variables and private/protected/public visibility. Also learn how Laravel uses magic methods.

You don't need this as a beginner, but as your code grows, it's crucial.

Sometimes you may want to execute DB queries in blade. There are some ok use cases for this, such as in layout files.

But if it's a view returned by a controller, pass the data in the view data instead. https://t.co/olodRS3N9s

This is similar to how I was throwing an exception based on certain things in the example with order locking. https://t.co/fg5z2TWGZx

This example is from Tenancy v2 when we had an ActiveRecord-style custom Tenant object. https://t.co/kydWSrcmer

Except...

It's multi-tenant!

Tip 7: It's incredibly easy to use https://t.co/XDsbINZGoO with Tinker 😎 https://t.co/kyk0A0te2M