The Symfony Framework Best Practices (Symfony Docs)

This article describes the best practices for developing web applications with Symfony that fit the philosophy envisioned by the original Symfony creators.
If you don't agree with some of these recommendations, they might be a good starting point that you can then extend and fit to your specific needs. You can even ignore them completely and continue using your own best practices and methodologies. Symfony is flexible enough to adapt to your needs.
This article assumes that you already have experience developing Symfony applications. If you don't, first read the Getting Started section of the documentation.
Symfony provides a sample application called Symfony Demo that follows all these best practices, so you can experience them in practice.
The Symfony binary is an executable command created on your machine when you download Symfony. It provides multiple utilities, including the simplest way to create new Symfony applications:
Internally, this Symfony binary command executes the needed Composer command to create a new Symfony application based on the current stable version.
Unless your project follows a development practice that imposes a certain directory structure, follow the default Symfony directory structure. It's flat, self-explanatory and not coupled to Symfony:
The values of these options change from one machine to another (e.g. from your development machine to the production server), but they don't modify the application behavior.
Use env vars in your project to define these options and create multiple .env files to configure env vars per environment.
When your application has sensitive configuration, like an API key, you should store those securely via Symfony's secrets management system.
These are the options used to modify the application behavior, such as the sender of email notifications, or the enabled feature toggles. Their value doesn't change per machine, so don't define them as environment variables.
Define these options as parameters in the config/services.yaml file. You can override these options per environment in the config/services_dev.yaml and config/services_prod.yaml files.
Unless the application configuration is reused multiple times and needs rigid validation, do not use the Config component to define the options.
Consider using app. as the prefix of your parameters to avoid collisions with Symfony and third-party bundles/libraries parameters. Then, use only one or two words to describe the purpose of the parameter:
Configuration options like the number of items to display in some listing rarely change. Instead of defining them as configuration parameters, define them as PHP constants in the related classes. Example:
The main advantage of constants is that you can use them everywhere, including Twig templates and Doctrine entities, whereas parameters are only available from places with access to the service container.
The only notable disadvantage of using constants for this kind of configuration values is that it's complicated to redefine their values in your tests.
A bundle is meant to be a piece of software that can be reused as a stand-alone component. Don't create bundles to organize your own internal application logic: use PHP namespaces (under the App\ namespace) to structure your code instead.
If you need to reuse a feature across several of your projects, then create a bundle for it (in a private repository; you don't need to make it public).
Service autowiring is a feature that reads the type-hints on your constructor (or other methods) and automatically passes the correct services to each method, making it unnecessary to configure services explicitly and simplifying the application maintenance.
Use it in combination with service autoconfiguration to also add service tags to the services needing them, such as Twig extensions, event subscribers, etc.
Make services private to prevent you from accessing those services via $container->get(). Instead, you will need to use proper dependency injection.
If you use the default services.yaml configuration, most services are configured automatically thanks to autowiring and autoconfiguration, so you rarely need to configure them by hand. When some service configuration belongs next to your code, use attributes such as #[Autowire].
For the remaining manual service configuration, both YAML and PHP work well: YAML is concise and friendly to newcomers, while PHP config adds type-safety and IDE autocompletion. Pick one format and use it consistently across your project.
Doctrine entities are plain PHP objects that you store in some "database". Doctrine only knows about your entities through the mapping metadata configured for your model classes.
Doctrine supports several metadata formats, but it's recommended to use PHP attributes because they are by far the most convenient and agile way of setting up and looking for mapping information.
Symfony provides a base controller which includes shortcuts for the most common needs such as rendering templates or checking security permissions.
Extending your controllers from this base controller couples your application to Symfony. Coupling is generally wrong, but it may be OK in this case because controllers shouldn't contain any business logic. Controllers should contain nothing more than a few lines of glue-code, so you are not coupling the important parts of your application.
Using attributes for routing, caching, and security simplifies configuration. You don't need to browse several files created with different formats (YAML, PHP): all the configuration is just where you require it, and it only uses one format.
If you extend the base AbstractController, you can only get access to the most common services (e.g. twig, router, doctrine, etc.) directly from the container via $this->container->get(). Instead, you must use dependency injection to fetch services by type-hinting action method arguments or constructor arguments.
If you're using Doctrine, then you can optionally