THAKURCODER BLOG

Introduction

Laravel is a robust and versatile PHP framework widely favored for building modern web applications. Despite its flexibility and power, many developers—both novice and experienced—fall into certain bad practices that can hamper performance, maintainability, and scalability. In this blog, we'll explore over 17 Laravel practices you should avoid to keep your codebase clean, efficient, and easy to manage.

1. Hardcoding Configuration Values

Why It’s Bad:

Hardcoding values like API keys, database credentials, or environment-specific settings within your code can lead to security issues and complicate the deployment process.

What to Do Instead:

Use Laravel’s configuration files and .env file for setting environment-specific configurations.

// Bad Practice
$apiKey = '12345';

// Good Practice
$apiKey = config('services.api_key');

2. Using Raw SQL Queries

Why It’s Bad:

Raw SQL queries can make your application susceptible to SQL injection attacks and make your code harder to maintain.

What to Do Instead:

Utilize Eloquent ORM or Laravel's query builder to interact with your database safely.

// Bad Practice
$results = DB::select('SELECT * FROM users WHERE active = 1');

// Good Practice
$results = User::where('active', 1)->get();

3. Ignoring Laravel’s Dependency Injection

Why It’s Bad:

Ignoring dependency injection leads to tightly coupled code, making it difficult to test and maintain.

What to Do Instead:

Leverage Laravel's built-in service container for injecting dependencies.

// Bad Practice
class UserController {
    protected $service;

    public function __construct() {
        $this->service = new UserService();
    }
}

// Good Practice
class UserController {
    protected $service;

    public function __construct(UserService $service) {
        $this->service = $service;
    }
}

4. Using Facades in Large Methods

Why It’s Bad:

While facades are convenient, overusing them in large methods can lead to less readable and less testable code.

What to Do Instead:

Restrict facade usage and prefer dependency injection where applicable.

// Bad Practice
class UserController {
    public function index() {
        return View::make('users.index')->with('users', User::all());
    }
}

// Good Practice
class UserController {
    protected $view;

    public function __construct(ViewFactory $view) {
        $this->view = $view;
    }

    public function index() {
        return $this->view->make('users.index')->with('users', User::all());
    }
}

5. Not Using Form Requests for Validation

Why It’s Bad:

Embedding validation logic directly in controllers can clutter your code and violate the Single Responsibility Principle.

What to Do Instead:

Use Laravel’s form request classes to handle validation.

// Bad Practice
public function store(Request $request) {
    $this->validate($request, [
        'name' => 'required',
        'email' => 'required|email',
    ]);

    // ...
}

// Good Practice
public function store(UserRequest $request) {
    // The validation is already handled by the form request class.
    // ...
}

6. Neglecting to Use Eloquent Relationships

Why It’s Bad:

Manually managing relationships between entities can result in more complex and error-prone code.

What to Do Instead:

Define relationships using Eloquent to simplify data retrieval and manipulation.

// Bad Practice
$posts = DB::table('posts')->where('user_id', $userId)->get();

// Good Practice
$posts = User::find($userId)->posts;

7. Overloading Controllers with Business Logic

Why It’s Bad:

Putting too much logic in controllers can make them difficult to manage and test.

What to Do Instead:

Move business logic to service classes or model methods.

// Bad Practice
class OrderController {
    public function complete($orderId) {
        $order = Order::find($orderId);
        $order->status = 'completed';
        $order->save();
    }
}

// Good Practice
class OrderService {
    public function complete(Order $order) {
        $order->status = 'completed';
        $order->save();
    }
}

class OrderController {
    protected $orderService;

    public function __construct(OrderService $orderService) {
        $this->orderService = $orderService;
    }

    public function complete($orderId) {
        $order = Order::find($orderId);
        $this->orderService->complete($order);
    }
}

8. Misusing Middleware

Why It’s Bad:

Using middleware for tasks that don’t involve HTTP request or response manipulation can lead to convoluted code.

What to Do Instead:

Use middleware only for HTTP concerns and handle other logic in appropriate locations like controllers or service classes.

9. Avoiding Eloquent Scopes

Why It’s Bad:

Repeating query logic across different parts of your application can lead to inconsistencies and harder maintenance.

What to Do Instead:

Use Eloquent query scopes for reusable query logic.

// Bad Practice
$activeUsers = User::where('active', 1)->get();

// Good Practice
$activeUsers = User::active()->get();

10. Failing to Handle Exceptions Properly

Why It’s Bad:

Catching and ignoring exceptions or failing to handle them appropriately can lead to unstable applications.

What to Do Instead:

Use Laravel's built-in exception handling mechanisms and create custom exception handlers where necessary.

// Bad Practice
try {
    // Some code
} catch (\Exception $e) {
    // Ignore exception
}

// Good Practice
try {
    // Some code
} catch (\Exception $e) {
    report($e);
    return response()->json(['error' => $e->getMessage()], 500);
}

11. Underusing Blade Components

Why It’s Bad:

Not utilizing Blade components can lead to duplicated HTML and make templates harder to maintain.

What to Do Instead:

Use Blade components and slots to reuse common UI elements.

// Bad Practice
<div class="card">
    <div class="card-header">Header</div>
    <div class="card-body">Body</div>
</div>

// Good Practice
<x-card>
    <x-slot name="header">Header</x-slot>
    Body
</x-card>

12. Skipping Unit Tests

Why It’s Bad:

Not writing tests can make it difficult to ensure the reliability and correctness of your code.

What to Do Instead:

Use Laravel’s testing tools to write unit tests for your application.

// Bad Practice
// No tests

// Good Practice
public function testUserCreation() {
    $user = User::factory()->create();
    $this->assertDatabaseHas('users', ['id' => $user->id]);
}

13. Failing to Leverage Event-Driven Architecture

Why It’s Bad:

Handling all operations synchronously can reduce your application’s performance and responsiveness.

What to Do Instead:

Use Laravel's event and listener system to manage tasks asynchronously.

// Bad Practice
public function completeOrder(Order $order) {
    // Update order status
    // Send notification
    // Update inventory
}

// Good Practice
public function completeOrder(Order $order) {
    $order->updateStatus('completed');
    event(new OrderCompleted($order));
}

14. Not Caching Queries and Views

Why It’s Bad:

Failing to cache frequently accessed data or views can slow down your application.

What to Do Instead:

Use Laravel's caching mechanisms to improve performance.

// Bad Practice
$users = User::all();

// Good Practice
$users = Cache::remember('users', 60, function () {
    return User::all();
});

15. Ignoring Security Best Practices

Why It’s Bad:

Neglecting security can make your application vulnerable to attacks.

What to Do Instead:

Follow Laravel’s security recommendations, including using CSRF tokens, validating inputs, and avoiding XSS vulnerabilities.

16. Not Using Migrations for Database Changes

Why It’s Bad:

Directly modifying the database can lead to inconsistencies and makes it hard to track changes.

What to Do Instead:

Use Laravel migrations for all database changes to maintain version control.

17. Underutilizing Laravel’s Built-In Tools

Why It’s Bad:

Rewriting functionality that Laravel already provides can waste time and introduce bugs.

What to Do Instead:

Familiarize yourself with Laravel's built-in tools and utilities and use them wherever possible.

18. Disregarding Code Readability and Standards

Why It’s Bad:

Unreadable code is harder to maintain and debug.

What to Do Instead:

Follow Laravel's coding standards and make use of tools like PHP-CS-Fixer to enforce style guides.

Conclusion

Avoiding these bad practices in Laravel can significantly enhance your application's performance, security, and maintainability. By adhering to Laravel’s best practices, leveraging its powerful features, and writing clean, maintainable code, you ensure that your application is robust and future-proof. Embrace these guidelines and keep your Laravel projects in top shape!