So, as you know, I’m a big fan of Laravel, in particular Eloquent is my favourite.
The beauty and value of both is a lot of conventions and magic happening behind the scenes. That magic, when balanced, allows us focus on things that really matter, rather than taking care of boilerplate and tedious, repetitive tasks, we’ve all been doing so many times. However…

… just like with legandary Freddie’s L0VE, too much of this magic will actually kill you (or at least bite your ass and take your valuable time).

In the Laravel community there are so many great people sharing their ideas, it’s simply a pleasure to be a part of it. Sometimes, however, I can see that excess of magic that imminently leads to trouble.

So after all those years writing, reading, understanding the code, here’s my advice on the very basic level of GOOD CODE:

Good code is predictable (thus easy to understand).

Now, let’s see exactly what I mean by that and where the problems can be found:

1. Caleb Porzio, who you should definitely follow, as he shares great insights, once did something that I definitely discourage:


So this pleasant refactoring might be pleasant for the sake of refactoring, but its value is negative. The code AFTER is much less readable, unintuitive, and you need to spend at least couple of seconds every single time you get back to it, don’t take my word, just try.

If you felt that code on the left needed refactoring, then I would suggest:

  • something that makes it easier for human eye to grasp in one go
  • something that really simplifies conditionals (separate IFs with early returns rather than one huge IF/ELSIF)
  • something that comes naturally (like positioning variable between range boundaries).

Something between the lines of:



2. Next, I came across advice, that actually makes sense, but at the same time works against the Laravel magic that would be on your side otherwise. This one is authored by Chris Gmyr (also great guy, who shares his knowledge and create OS stuff):


Well, this one might be really tempting. But, do you really need that distinction? Admin vs Customer only in order to apply simple where? I don’t think so, but that might be a matter of preference.

Here, however, the problems strike when you expect them least. There are couple of things missing here:


In order to resolve the issues you would add protected $table = 'users'; and override getForeignKey method, but if you later need to use similar logic directly on your User model, you hit exactly the same wall, only on the other side..

Instead use what Eloquent already provides for you to solve such cases:



3. And yet another rabbit from the hat:


Well… Yes, you can. And No, you definitely should not do it. You, your neighbour and their dog will thank you later.


And what do you think – To M4g1c OR not to magic?


It's only fair to share...Tweet about this on TwitterShare on RedditPin on PinterestShare on FacebookShare on Google+

Related Post

Tinker like a boss – WTF?! This is part of the series tinker like a boss (in psysh) tinker... what? includes casters (presenters) aliases http (and other) helpers ...
they can bite! – how (not) to use accessors ... Eloquent mutators & accessors are handy feature that can simplify your high level code and hide some data-related logic in the model. Howev...
PHP how to use $this in Closure – context ma... Anonymous functions, in php known as Closures, come in handy very often. One application in particular is very useful - extending classes, thanks ...
Revisionable – a quick example A short reminder about my revisionable package (compatible with L4 & L5+) and quick example of how you can use it: 1. Controller: 2....