What are the Slack Archives?

It’s a history of our time together in the Slack Community! There’s a ton of knowledge in here, so feel free to search through the archives for a possible answer to your question.

Because this space is not active, you won’t be able to create a new post or comment here. If you have a question or want to start a discussion about something, head over to our categories and pick one to post in! You can always refer back to a post from Slack Archives if needed; just copy the link to use it as a reference..

Hello, short question understanding the phpcs rules: Is there a reason using FQCN for every generate

UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet

short question understanding the phpcs rules: Is there a reason using FQCN for every generated class? From my perspective its more practical to import namespaces since its easier to deal with, even with alias (“… as SprykerBusinessFactory”).


  • U01A1HDSVS8
    U01A1HDSVS8 Posts: 17 🧑🏻‍🚀 - Cadet

    I think it applies just to phpdoc. This way you do not have to scroll or ask your ide in case you wonder what exact class is used in that place. Adding the FQCN to the phpdoc will not create additonal lines as the line is there anyway.

    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet
    edited September 2020

    But lets pick this one

    use Spryker\Zed\Kernel\Container;
    * @param \Spryker\Zed\Kernel\Container $container
    * @return \Spryker\Shared\Kernel\ContainerInterface
    public function provideBusinessLayerDependencies(Container $container): ContainerInterface

    When the Container now changes to another Container from another namespace, you have to change the use statement but also the comment … EACH comment from each function …

    I would also think it the way around: Using the IDE would make it more easy to read what specific namespace is meant on that place (by hovering over the class). Just when not using an IDE its more difficult to read since you must scroll.

    Even using an alias + convention would be better than an FQCN in that case.

    So for me in the end it decreases maintainability for a not really existing advantage in readability (due to using IDE).

  • Unknown
    edited September 2020

    The reason comments/docblocks are ideally FQCN:
    They should not require include of use statements for themselves (mixing "functional" vs "non functional"), nor should they be partially invalid/incomplete when being moved or copied to docs or alike.
    They serve an important role here as such, even if they might be a bit longer than it appears to be necessary.

    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet

    Ah okay. Thats a valid point for me … one day we hopefully get rid of all the type stuff in the docs … Thanks a lot guys.

  • At least with IDE+tooling they will be auto added/synced pretty much. So no pain/issue for the next years even.

    UPWG9AYH2 Posts: 509 🧑🏻‍🚀 - Cadet

    Would be good anyway to have it not documented twice^^ hopefully we get someday at least that typing stuff fully supported by php

  • Unknown
    edited September 2020

    It isn't documented twice though 🙂 Only once. The other is functional code (with use statements too far away for readability on the types, even more so for screenshots or in PR reviews).