Laravel has quickly gained popularity and has asserted itself as the leading MVC PHP framework in 2015 and 2016. Many developers have joined the Laravel wave, many of which have very limited development experience outside the framework. Out of the box Laravel is prepared to be this lean development tool, that you just plug in and use. Well not always, as many traps are awaiting the unsuspecting developer.

1. Not Using Controllers in Router File

Most of the starting titorials come with very basic examples, functional routes, method specific routes, of resource routes. As these are a starting learning point for many developers, these become a habit, and not many developers look any further. Once the code base starts to grow, router file grows, to the point its hard to grasp. If your router file is more than 30 lines, then probably you have grasped this bad habit.

Using controller based routes is advanced method and will help keeping your router files neat, and to the point.

2. Keeping Business Logic Outside the Controller

If you have the notion that Controller should be slim and neat and try to place your logic somewhere else, you have got it wrong, and its going to bite you later. Do you have helper files, repositories, services, contracts, or presenters? Well, its a sign you try to get business logic outside of where it need to be. Remember, anything which involves busines logic should be in the controller. Period.

3. Watching Laracast

Many developers watch Laracast in order to learn programming in Laravel. To put it mildly, Laracast is the worst place to learn anything. Simple, very abstract examples, not linked to real live. And showing junior developers how to implement any design patern under the sun.

4. Trying to Abstract Database Models

As part of the above many developers in Laravel try to abstract models, when they do not need to. Guess what what, you are building an abstraction over an abstraction. As Laravel models are already an abstraction for the database. The model abstractions in Laravel are usually called repositories, and are being advocated as "best practice".  There is a place where repositories might be helpful in 0.001% of user cases. But in reality, if you have to use repositories to mask models, your code is seriously flawed.

5. Too Many Classes

Are you trying to make a class of every line of code. From this nice and easy mail function, thats a single line of code. Lest make a mail contract class, and interface, and finally make into a service. Do you say its "scalable" or "its the Laravel way of doing it"? Well, well, welcome to the code bloat.

6. Not Reading Enough

Do you try to make it something and it takes a long time? Do you struggle to get something working? Guess what. Its most probably already bolted in Laravel. Read the documentation. And read it again, until you know by heart. Only then you will be able to weed out the good parts from the bad parts (and there are many of them).

7. Using the Bolted Authentication Package

The bolted authentication package is flawed in so many ways. Its a very basic package with login screen, reset password, etc. The issue is it is provided in such a "magical" way, that its impossible to change without spending too much time, and even then works as a foreign piece of code. Its enough to say the package uses Traits to make any sane developer run away (i.e. ThrottlesLogins and AuthenticatesAndRegistersUsers). I had the misfortune to have to modify it several times to fit custom logins. My advice, do not use it. In one hour you may have all this functionality bolted in, which you can reuse anywhere. In additiion being open source, means not very secure. Pretty much everybody can have a look at your login, and guess what bad guys will not come tell you when there is a flaw.

8. Not Knowing PHP Good Enough

If you are not able to write what you do in Laravel in pure PHP, then you are in trouble. You will always tend to overcomplicate, instead of simplify. And you will not be able to make pragmatic decissions.

9. Not Knowing At Least Three Other MVC Frameworks

Laravel will lie to you. Inintentionally of course. It has bolted so many functionalities, that it is easy to get mislead on how MVC works, what is important, and what is total BS. The only way to make your way through the labyrinth is to know why something works the way it works, and why a feature is a BS, before you even try using it. Simple example: Laravel presenters, listeners, broadcasters and events -- great examples how the road to hell is paved with good intentions.