Laravel Naming conventions

In Laravel, naming conventions are essential for maintaining a clean and consistent codebase. Following naming conventions makes your code more readable and understandable for other developers who might work on your project. Here are some common naming conventions used in Laravel:

1. Class Names:

• Studly Case: Class names should be in StudlyCase, also known as PascalCase, where each word in the class name starts with a capital letter and there are no separators between words. For example: UserController, PostController.

2. Method Names:

• Camel Case: Method names should be in camelCase, where the first word is in lowercase and subsequent words start with a capital letter. For example: getUserById, createNewPost.

3. Variable Names:

• Camel Case: Variable names should also be in camelCase. For example: $userName, $postContent.

4. Table Names:

• Plural Form: Table names should be in plural form. For example, if you have a table for users, the table name should be users, not user.

5. Column Names:

• Snake Case: Column names should be in snake_case, where words are separated by underscores. For example: first_name, email_address.

6. Route Names:

• Descriptive Names: Route names should be descriptive and follow a logical naming convention. For example, if you have a route to show a user profile, you might name it profile.show.

7. View Names:

• Descriptive Names: Views should have descriptive names that reflect their purpose. For example, if you have a view for displaying user information, you might name it user_profile.blade.php.

8. Configuration File Names:

• Snake Case: Configuration file names should be in snake_case. For example, database.php, mail.php.

9. Resource Names:

• Plural Form: Resource names should be in plural form to represent a collection of resources. For example, if you have a resource for managing posts, you might name it PostsResource.

Follow Laravel naming conventions

Follow PSR standards.

Also, follow naming conventions accepted by Laravel community:

Convention over configuration

As long as you follow certain conventions, you do not need to add additional configuration.

Bad:

// Table name 'Customer'
// Primary key 'customer_id'
class Customer extends Model
{
    const CREATED_AT = 'created_at';
    const UPDATED_AT = 'updated_at';
    protected $table = 'Customer';
    protected $primaryKey = 'customer_id';
    public function roles(): BelongsToMany
    {
        return $this->belongsToMany(Role::class, 'role_customer', 'customer_id', 'role_id');
    }
}

Good:

// Table name 'customers'
// Primary key 'id'
class Customer extends Model
{
    public function roles(): BelongsToMany
    {
        return $this->belongsToMany(Role::class);
    }
}

Use shorter and more readable syntax where possible

Bad:

$request->session()->get('cart');
$request->input('name');

Good:

session('cart');
$request->name;

More examples:

Use IoC / Service container instead of new Class

new Class syntax creates tight coupling between classes and complicates testing. Use IoC container or facades instead.

Bad:

$user = new User;
$user->create($request->validated());

Good:

public function __construct(User $user)
{
    $this->user = $user;
}
...
$this->user->create($request->validated());

Do not get data from the .env file directly

Pass the data to config files instead and then use the config() helper function to use the data in an application.

Bad:

$apiKey = env('API_KEY');

Good:

// config/api.php
'key' => env('API_KEY'),
// Use the data
$apiKey = config('api.key');

Store dates in the standard format. Use accessors and mutators to modify date format

A date as a string is less reliable than an object instance, e.g. a Carbon-instance. It's recommended to pass Carbon objects between classes instead of date strings. Rendering should be done in the display layer (templates):

Bad:

{{ Carbon::createFromFormat('Y-d-m H-i', $object->ordered_at)->toDateString() }}
{{ Carbon::createFromFormat('Y-d-m H-i', $object->ordered_at)->format('m-d') }}

Good:

// Model
protected $casts = [
    'ordered_at' => 'datetime',
];
// Blade view
{{ $object->ordered_at->toDateString() }}
{{ $object->ordered_at->format('m-d') }}

Do not use DocBlocks

DocBlocks reduce readability. Use a descriptive method name and modern PHP features like return type hints instead.

Bad:

/**
 * The function checks if given string is a valid ASCII string
 *
 * @param string $string String we get from frontend which might contain
 *                       illegal characters. Returns True is the string
 *                       is valid.
 *
 * @return bool
 * @author  John Smith
 *
 * @license GPL
 */
public function checkString($string)
{
}

Good:

public function isValidAsciiString(string $string): bool
{
}

Other good practices

Avoid using patterns and tools that are alien to Laravel and similar frameworks (i.e. RoR, Django). If you like Symfony (or Spring) approach for building apps, it's a good idea to use these frameworks instead.

Never put any logic in routes files.

Minimize usage of vanilla PHP in Blade templates.

Use in-memory DB for testing.

Do not override standard framework features to avoid problems related to updating the framework version and many other issues.

Use modern PHP syntax where possible, but don't forget about readability.

Avoid using View Composers and similar tools unless you really know what you're doing. In most cases, there is a better way to solve the problem.

Use standard Laravel tools accepted by community

Prefer to use built-in Laravel functionality and community packages instead of using 3rd party packages and tools. Any developer who will work with your app in the future will need to learn new tools. Also, chances to get help from the Laravel community are significantly lower when you're using a 3rd party package or tool. Do not make your client pay for that.