More changes after reviews

Author: javiereguiluz

best_practices.rst

@@ -32,30 +32,14 @@ to create new Symfony applications:
     $ symfony new my_project_name
 
 Under the hood, this Symfony binary command executes the needed `Composer`_
-command to create a new Symfony application based on the current stable version.
+command to :ref:`create a new Symfony application <creating-symfony-applications>`
+based on the current stable version.
 
-Use the Symfony Skeleton to Create New Symfony-based Projects
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-Symfony provides two "skeletons" (or "project templates") to
-:ref:`create new Symfony projects <creating-symfony-applications>`. Use the
-minimal "skeleton" to start small and get the best performance and grow your
-application later as needed.
-
-Use Composer and Symfony Flex to Manage Symfony Applications
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-`Composer`_ is the package manager used by modern PHP applications to manage
-their dependencies. :ref:`Symfony Flex <symfony-flex>` is a Composer plugin
-designed to automate some of the most common tasks performed in Symfony
-applications. Using Flex is optional but recommended because it improves your
-productivity significantly.
-
-Use the Directory Structure Proposed by Flex
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+Use the Default Directory Structure
+~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Unless your project follows a development practice that imposes a certain
-directory structure, follow the structure proposed by Symfony Flex. It's flat,
+directory structure, follow the default Symfony directory structure. It's flat,
 self-explanatory and not coupled to Symfony:
 
 .. code-block:: text
@@ -108,7 +92,7 @@ Use Parameters for Application Configuration
 
 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 it's not worth it to define them as environment variables.
+change per machine, so don't define them as environment variables.
 
 Define these options as :ref:`parameters <configuration-parameters>` in the
 ``config/services.yaml`` file. You can override these options per
@@ -165,17 +149,14 @@ Business Logic
 Don't Create any Bundle to Organize your Application Logic
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
-When Symfony 2.0 was released, Symfony applications used bundles to divide their
-code into logical features: UserBundle, ProductBundle, InvoiceBundle, etc.
+When Symfony 2.0 was released, applications used :doc:`bundles </bundles>` to
+divide their code into logical features: UserBundle, ProductBundle,
+InvoiceBundle, etc. However, a bundle is meant to be something that can be
+reused as a stand-alone piece of software.
 
-However, a bundle is meant to be something that can be reused as a stand-alone
-piece of software. If UserBundle cannot be used "as is" in other Symfony
-applications, then it shouldn't be its own bundle. Moreover, if InvoiceBundle
-depends on ProductBundle, then there's no advantage to having two separate bundles.
-
-Symfony applications can still use third-party bundles (installed in ``vendor/``)
-to add features, but you should use PHP namespaces instead of bundles to organize
-your own code.
+If you need to reuse some feature in your projects, create a bundle for it (in a
+private repository, to not make it publicly available). For the rest of your
+application code, use PHP namespaces to organize code instead of bundles.
 
 Use Autowiring to Automate the Configuration of Application Services
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -204,8 +185,7 @@ most services will be configured automatically. However, in some edge cases
 you'll need to configure services (or parts of them) manually.
 
 YAML is the format recommended to configure services because it's friendly to
-newcomers and concise, but Symfony also supports XML and PHP configuration, so
-you can use whatever format you like.
+newcomers and concise, but Symfony also supports XML and PHP configuration.
 
 Use Annotations to Define the Doctrine Entity Mapping
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
@@ -240,13 +220,9 @@ Use Annotations to Configure Routing, Caching and Security
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
 Using annotations for routing, caching and security simplifies configuration.
-You don't need to browse tens of files created with different formats (YAML, XML,
+You don't need to browse several files created with different formats (YAML, XML,
 PHP): all the configuration is just where you need it and it only uses one format.
 
-The only exception is when the annotations are too complex, such as when using
-long expressions in the ``@Security`` annotation or lots of variables and
-requirements in the ``@Route`` annotation.
-
 Don't Use Annotations to Configure the Controller Template
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
@@ -278,13 +254,6 @@ the controller (e.g. by calling to a :doc:`Doctrine repository method </doctrine
 Templates
 ---------
 
-Use Twig to Create your Templates
-~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
-
-:ref:`Twig <twig-language>` is more concise, readable and safe than PHP. Its
-performance is comparable because Symfony compiles Twig templates to PHP and
-caches the result.
-
 Use Snake Case for Template Names and Variables
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~