SitePoint Sponsor

User Tag List

Results 1 to 17 of 17
  1. #1
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    England
    Posts
    698
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)

    Who uses PSR standards for their code?

    Just curious. I've used the PSR-0 autoloader standard for some time now, but only recently discovered the PSR-1 coding standard and the PSR-2 style guidelines.

    I understand that these have been drawn up by the PHP Frameworks Interoperability Group, and the focus is to be able to share libraries between the frameworks easily, so it doesn't actually affect the average developer (unless you want to use framework library code, that is), but I find that coding standards are severely lacking in PHP and I agree with much of what they require (an exception being that the opening brace for class/method/etc is on the next line, but the same line for loops and conditions) so I decided I'm going to adhere as much as possible. Previously I used to code to the Zend Framework 1 guidelines.

    So does anyone else code to these, and what are your thoughts on them? Do you vehemently object to anything? The tabs-vs-spaces thing seems to be an item of much contention, I find.

  2. #2
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Yup, I use them and we use them at work too. I've always argued strongly in favour of spaces over tabs so that suits me (work switched styles to follow PSR)

  3. #3
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    I find the entire thing a bit of a joke really. PSR-0 is backwards. Structuring your files to suit your autoloader rather than your autoloader to suit your file structure is a terrible idea.

    As for PSR-1 and PSR-2, following them, or not following them, is going to have zero impact on anything really. If it suits your style anyway, do it, if it doesn't, it doesn't matter if you don't use them. Keep in mind that any decent IDE can format the code in the way you prefer as you open a file.

  4. #4
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    England
    Posts
    698
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    I disagree about PSR-0, though I do appreciate your reasoning.

    Due to the organisational structure defined in PSR-0 it is really easy to write a simple, compatible autoloader that will allow you to use libraries from various frameworks, even if your application code base is completely different. If you conform to their namespace specification as well (\vendor\package\etc) then it also provides a well structured organisation of your own code. If you were to replicate that into a file structure such as /libraries/vendor/package/etc.php then it's easy to understand where files are and you have no messing when implementing other people's libs. I like if for that simplicity. We've used libs from Symfony, Zend, Guzzle, Doctrine and more, and it all just works with a single autoloader. Maybe it is just more suitable for us than for others, but I like it. It also means that my code will work with other people's frameworks if they want to use it, which makes it more worth my while.

    As for reformatting code when you open a file, that will lead to unnecessary commits to your VCS as files will be detected as changed. It's much simpler if everyone works to the same standard. Whether you use PSR standards or not, reformatting when you load a file isn't the answer IMHO.

  5. #5
    SitePoint Wizard silver trophybronze trophy Stormrider's Avatar
    Join Date
    Sep 2006
    Location
    Nottingham, UK
    Posts
    3,133
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    I find the entire thing a bit of a joke really. PSR-0 is backwards. Structuring your files to suit your autoloader rather than your autoloader to suit your file structure is a terrible idea.
    PSR-0 is going to be replaced soon anyway with PSR-4 which I think addresses this a bit. Also, I think it's important for everyone on a team to work to the same coding standards, so like PSR-1 and PSR-2 for these - the point about version control is a good one. Given that several large projects have signed up to these standards, they are as good as any to follow. They closely match what I did before anyway (other than I used 2 space indents and put the opening brace of functions, methods and classes on the same line). I don't think it matters what standards a team uses (though I have strong opinions on tabs vs spaces!), as long as they all use the same one and can reasonably justify why they use them.

  6. #6
    Community Advisor bronze trophy
    fretburner's Avatar
    Join Date
    Apr 2013
    Location
    Brazil
    Posts
    1,433
    Mentioned
    45 Post(s)
    Tagged
    13 Thread(s)
    Quote Originally Posted by Stormrider View Post
    PSR-0 is going to be replaced soon anyway with PSR-4
    I think the intention is not for PSR-4 to replace PSR-0. It seem that the differences between the two are rather minor anyway, and basically allow a slightly different directory layout: http://philsturgeon.co.uk/blog/2013/...-not-relatives

  7. #7
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Which is exactly the reason that the standard is backwards. They need a whole new standard for these cases where someone wants to do something negligibly different. As I suggested on my blog (and had a big debate with Phil Sturgeon on his), it's totally inefficient. The standard should provide a way for library authors to tell the autoloader where their files are rather than forcing library authors to follow a specific convention. Then we wouldn't need PSR-0... and we wouldn't need to completely restructure and add namespaces to non-compliant libraries to fit the standard, we'd just provide the relevant metadata to the autoloader. But the PSR guys don't like criticism so I gave up trying to talk sense to them.

  8. #8
    SitePoint Addict bronze trophy Hall of Famer's Avatar
    Join Date
    Apr 2013
    Location
    Ithaca
    Posts
    368
    Mentioned
    6 Post(s)
    Tagged
    2 Thread(s)
    I follow some of these rules, but not everything. I never start a new line after defining a class or method, its the way CakePHP does thing too but I actually dont use Cake since I prefer DataMapper over Active Record.

  9. #9
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    692
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by TomB View Post
    ...As I suggested on my blog (and had a big debate with Phil Sturgeon on his), ...
    I reread your blog. You make some good points and you are clearly passionate about your ideas. I think the notion of adding an autoload.json file to a project which specifies autoload rules is a good one. You really should make a formal "request for comment" (RFC) somewhere and see if it gets any traction. Or maybe even propose a patch to composer.

  10. #10
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    England
    Posts
    698
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    What does Composer have to do with autoloading?

    To be fair, Tom does make a good point that some kind of metadata would be better. I suppose in a similar way to how ZF2 works with routing?

  11. #11
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    692
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Antnee View Post
    What does Composer have to do with autoloading?
    As part of the composer install/update process, composer will create a vendor/autoload.php file. In many cases all your application has to do is include vendor/autoload.php and viola, everything will auto load. It's really quite nice.

  12. #12
    Non-Member
    Join Date
    Oct 2007
    Posts
    363
    Mentioned
    11 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by TomB View Post
    Which is exactly the reason that the standard is backwards. They need a whole new standard for these cases where someone wants to do something negligibly different. As I suggested on my blog (and had a big debate with Phil Sturgeon on his), it's totally inefficient. The standard should provide a way for library authors to tell the autoloader where their files are rather than forcing library authors to follow a specific convention. Then we wouldn't need PSR-0... and we wouldn't need to completely restructure and add namespaces to non-compliant libraries to fit the standard, we'd just provide the relevant metadata to the autoloader. But the PSR guys don't like criticism so I gave up trying to talk sense to them.
    I'm not sure I agree it is backwards.

    I quite like the idea of namespaces revealing the directory structure. It means I know exactly where each file will be in the filesystem based on the structure of the namespace. I don't see why this is a bad thing. I like it.

  13. #13
    SitePoint Guru bronze trophy TomB's Avatar
    Join Date
    Oct 2005
    Location
    Milton Keynes, UK
    Posts
    996
    Mentioned
    9 Post(s)
    Tagged
    2 Thread(s)
    Quote Originally Posted by aaarrrggh View Post
    I'm not sure I agree it is backwards.

    I quite like the idea of namespaces revealing the directory structure. It means I know exactly where each file will be in the filesystem based on the structure of the namespace. I don't see why this is a bad thing. I like it.
    In some cases it's perfectly fine. But imposing that on every library limits flexibility... which is never a good thing. Here's a really good explanation of several practical issues with it: http://scriptogr.am/mattsah/post/a-u...tique-of-psr-x However, when I was looking at implementing it I realised how ridiculous it was.

    I have a router with various rule types, these are classes, and generally project specific. The router itself sits in the namespace \Router\ The router is configured with rules in the namespace \Router\Conf. The rules are mostly project specific, while the router is the same for every project and sits at the library/framework level. Directory structure wise, this makes sense to store \Router\Router in /framework/router/router.php while storing project specific rules in /application/conf/router/$rule.php

    PSR-0 however, dictates this is not allowed and would force me to mix project-specific and library level code just because they have the same top level namespace.

    And before anyone says: "But the rules should be in \Conf\Router". No, they shouldn't because the router library shouldn't make assumptions that all the other libraries use a \Conf\ namespace for configuration.

    This is the same for any library where you'd want project specific related classes, and library supplied classes in the system.

  14. #14
    SitePoint Wizard bronze trophy Jeff Mott's Avatar
    Join Date
    Jul 2009
    Posts
    1,311
    Mentioned
    19 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by TomB View Post
    PSR-0 however, dictates this is not allowed and would force me to mix project-specific and library level code just because they have the same top level namespace.
    In this case, I think your clash with PSR-0 reveals an issue with your code, not with PSR-0.

    Your library code and your project-specific code almost certainly should not be sharing a namespace. Your library code should live in LibraryName\Router and your project-specific code should live in ProjectName\Conf\Router. Otherwise, one of them is polluting in the other's space.

    Quote Originally Posted by TomB View Post
    And before anyone says: "But the rules should be in \Conf\Router". No, they shouldn't because the router library shouldn't make assumptions that all the other libraries use a \Conf\ namespace for configuration.
    The router probably shouldn't make any assumptions at all about where the configuration lives. Otherwise your router is mandating how the larger application must be organized. The router should simply have its config injected. It doesn't need to know or care where the config data came from.

    EDIT: And even still, PSR-0 will absolutely let you do what you're describing.

    Code:
    $loader->registerNamespaces(array(
        'Router\\Conf'             => __DIR__.'/application/conf/router',
        'Router'                   => __DIR__.'/vendor/router',
    ));
    "First make it work. Then make it better."

  15. #15
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    692
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by TomB View Post
    PSR-0 however, dictates this is not allowed and would force me to mix project-specific and library level code just because they have the same top level namespace.
    Are your sure about that? I use the same top level namespace in my libraries and application all the time. I don't actually care if it is psr-0 compliant or not but Composer handles it just fine.

    The only relevant line is the spec that I could see is:

    Each namespace must have a top-level namespace ("Vendor Name").
    It doesn't say that the top level namespace needs to be unique. The autoloader certainly does not care.

  16. #16
    SitePoint Guru
    Join Date
    Nov 2004
    Location
    England
    Posts
    698
    Mentioned
    1 Post(s)
    Tagged
    0 Thread(s)
    Quote Originally Posted by ahundiak View Post
    As part of the composer install/update process, composer will create a vendor/autoload.php file. In many cases all your application has to do is include vendor/autoload.php and viola, everything will auto load. It's really quite nice.
    Sounds like you have Composer confused with the packages that you're installing with it: http://philsturgeon.co.uk/blog/2013/...-not-relatives

  17. #17
    SitePoint Guru
    Join Date
    Nov 2003
    Location
    Huntsville AL
    Posts
    692
    Mentioned
    4 Post(s)
    Tagged
    1 Thread(s)
    Quote Originally Posted by Antnee View Post
    Sounds like you have Composer confused with the packages that you're installing with it: http://philsturgeon.co.uk/blog/2013/...-not-relatives
    I freely admit to being confused about many things. Are you saying that composer doesn't generate a vendor/autoload.php? Are you saying that you can't have
    Code:
        "autoload": {
            "psr-0": { "": "src/" }
        },
    in your composer.json file?


Tags for this Thread

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •