What you should NOT do in Laravel

Among developers, especially with Laravel, there is great cooperation and helpfulness, and on Stack Overflow you get quick answers if you get stuck in your own code. The mistake that happens far too quickly here, however: The code is copied and pasted, but not really understood. The result is a ‘witch's brew of code’, a mixture of different styles, code blocks and design patterns that have been thrown together from all over the place. It can still work, but it's chaotic and not intuitive.

The consequence: If an error occurs in the future, it is much more difficult to determine the cause, and for other developers the code may not make sense at first glance if they do not know the history of its creation.

An example of "messy" code:

Chaos in the code also arises if you don't read the documentation properly. It is tempting to simply programme straight away, but the documentation often shows the cleanest and easiest way to implement something. Just like in our example:

Mostly applies: “Your application is only as good as your data”.

Chaos in the database can quickly backfire! Many developers concentrate solely on getting the application up and running as quickly as possible, without considering important aspects such as the structure and cleanliness of the database — and then zombie entries are created. 

A zombie entry is a child data record that is not assigned to a parent data record. This happens if the database was not structured correctly from the start. When creating the database, we should use foreign keys wherever possible to ensure that all relationships are defined correctly.

A typical reason for the poor performance of a Laravel project is the structure of Eloquent queries. Many of the things in Eloquent are hidden from the developers, and if you are not careful, strange and problematic things can happen, such as the N+1 query problem, or as we call it: ‘Eloquent Hell’

To avoid such problems, you should always pay attention to how queries are structured and use tools such as "Laravel Debugbar" or "Laravel Telescope" to recognise potential N+1 query problems at an early stage.

Our Halloween Meetup session showed us how easy it is to fall into scary code traps and how dangerous it can be to allow bad practices in our Laravel projects. The examples presented illustrate that care, understanding your tools and a good structure should be essential parts of any development process.

To ensure the performance and maintainability of our projects, it is important to always read the documentation, keep the database clean and keep an eye on the structure of the Eloquent queries. This way, we can ensure that our applications don't become a nightmare for future developers — or for ourselves. Stay vigilant, work thoroughly and beware of the code zombies!