As you use them repeatedly, you'll develop a sense for what's good code and what's bad code.
I'll also sprinkle some general Laravel code advice in between these tactics.
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.
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.
Avoid having classes that deal with many unrelated things
But, for the love of god, don't create a class for every single thing. You're trying to write clean code. You're not trying to please the separation gods
1. The function has too many responsibilities. Separate.
2. The responsibilities are fine, but you should refactor the long signature.
Below are two tactics for the fixing second case.
If you can, only use the 7 CRUD actions in your controllers. Often even fewer.
Don't create controllers with 20 methods.
More shorter controllers is better.
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.
Above you can see that I use space between ! and the value I'm negating. I like this, because it makes it clear that the value is being negated. I do the same around dots.
Decide if you like it. It can (imo) clean up your code.
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.
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.
Before writing a comment, ask yourself if you could rename some things or create variables to improve readability. If that's not possible, write the comment in a way that both your colleagues and you will understand in 6 months.
*Your goal to write more readable code.*
Your goal is NOT to do what someone said on the internet
These tips are just tactics that tend to help with clean code. Keep your end goal in mind and ask yourself "is this better?"