Prestashop: Respect PHP recommandations

[presteus]

Discusion open from #18628 (edit: https://github.com/PrestaShop/PrestaShop/issues/18626#issuecomment-613746699)

Is your feature request related to a problem?

The request is about the respect of PHP Recommandations like classnames and filenames (PSR 4).

Describe the solution you'd like

Simply apply PHP Recommandations from https://www.php-fig.org/psr/

Alternatives you've considered

No alternative available.

Additional context

Invoking breaking retrocompatibility is not a reason, a clear and concise documentation is enough

[prestashop-issue-bot[bot]]

Thanks for opening this issue! We will help you to keep its state consistent

[matks]

Hi @presteus,

• PSR1 and PSR2 are already enforced as we have a Github Action running PHP CS Fixer against all PRs
• PSR4 is used to autoload all modern classes in src folder, not-compliant legacy classes in other folders will slowly vanish over time

Invoking breaking retrocompatibility is not a reason, a clear and concise documentation is enough

Actually invoking breaking retrocompatibility is a very valid reason 😅

Imagine this the following scenario: you are a merchant using PrestaShop. Your shop is being managed and maintained by a web agency.
PS 1.7.8.0 is released. Great ! It brings some very good features you are expecting. You ask your agency yo do the upgrade. However agency tells you "In order to upgrade, we need you to pay 10,000€ as PrestaShop has introduced multiple BC breaks in this version in order to have PSR4 everywhere".
What do you think the merchant thoughts are ? He asks what PSR4 is. The agency answers. The merchant is baffled: why should he pay for 10,000 euros only because the code was changed without any behavior changes, only to comply to a standard he has no idea of ? 😅

PSR are a set of standards aiming for interoperability. It ensures the easy integration of a 3rd party library inside a project or another library because the autoloading strategy is known and reliable. No need to read the README or hack your way into the source code to find how to autoload it. Composer does it for you 💪

What I mean is that having the full code PSR4-compliant would be nice for interoperability but the price of the BC break is way too high for end-users to accept it.

PrestaShop compliancy to PSR4 will slow increase over time while we migrate legacy code (mostly in classes folder) to modern code (src) folder 😉. But we will never make classes folder PSR4 compliant in order not to introduce BC breaks.

In next major version, we will remove a set of legacy classes. Not all of them, but a set. Then another one in another major version (always major versions in order to comply to SemVer). And another one again ... until the folder classes is empty 😊. At this moment PrestaShop will be fuully PSR4-compliant.

[presteus]

For the BC, this is exactly what i think.
I talk about next major versions, actually i attempt to work with development branch since two weeks to create a docker with development version and day after day i have a new core error, it's a pain.

[matks]

For the BC, this is exactly what i think.
I talk about next major versions, actually i attempt to work with development branch since two weeks to create a docker with development version and day after day i have a new core error, it's a pain.

Have you looked at https://github.com/PrestaShop/docker ?

day after day i have a new core error, it's a pain.

Welcome in our life ! Are you available for hire :trollface: ?
This is why we migrate to Symfony and, while changing the framework, we rewrite the code. But it's a long journey.

[eternoendless]

We'll progressively get rid of *Core legacy classes as they are replaced in the Core. This, however, will take a long time.

I'm closing this issue because it's a known architecture problem that we're aware of and will be progressively be fixed.