4 ms·

I'm wondering why a specific code style is 'enforced' while it has nothing to do with interoperability. Libraries with different code styles can be used togeth

by _ikke_ 14y ago

I'm wondering why a specific code style is 'enforced' while it has nothing to do with interoperability. Libraries with different code styles can be used together without problems. It seems like they are using the PSR to declare they're own style as superior.

codeguy 14y ago
I think it's less about being "superior" than standardizing on a common style. Makes it easier to get up and running with someone else's code. But if your team agrees on a common but different style, that's fine too. It accomplishes the same goal. I'm only suggesting the official standard for new PHP developers.
- kellishaver 14y ago
  Right. I think the main take-away from it is to be consistent and make sure everyone on your team is on the same page about the coding style. I see the PSR as a basic set of good recommendations, rather than something that must be followed. It's a good idea to follow it, but at least follow something. My only complaint with it personally is that I Can. Not. Stand. putting opening brackets on their own line.
  - mgkimsal 14y ago
    I understand it's not an either/or situation but... I'd MUCH prefer people spend time writing tests for their code vs debating/arguing/refactoring code style. If your tests and good and coverage is high, there's far less chance I should ever even have to muck around inside your libraries, much less modify them. And again, one doesn't preclude the other, but I see so many people making a bit stink over style - tabs vs spaces et al years before the PSR stuff - yet rarely do I see even 20% of that effort spent on getting people to test. I say this not as someone who tests everything 100%, but as someone who doesn't do much of it, and understands the importance of it. When I'm deciding to use someone else's libraries, I never make a decision based on the code style they've chosen - I base it on maturity, documentation, and tests/examples provided (when there's a choice, sometimes you don't have a choice, or you roll your own). The really good libraries? I never even have to look a their code - it might be all run together on one line for all I care - it just works.
    - kellishaver 14y ago
      If a library works like it should, then you may never have to look at it - that's great. But if you're working on a team, you'll have to read and understand other people's code all the time, and even if you're not, someone, somewhere, is going to eventually want to make that library do something different. I agree that, of the two, good test coverage is more important than pretty formatting, but a good code style is going to make the code easier to debug when those tests fail and easier to extend when the library needs to do more. It's a simple matter adopt a coding style that works and stick with it, so there's really no good reason not to do it. By comparison, it does seem like a trivial thing to obsess over. There are a number of coding styles which are all fine in their own right. I think people should worry less about the specifics and more about the overall intent-to write consistent, clean code. How many blank lines you have after block of code or where you put the opening bracket doesn't really mater in the end, as long as you follow the same structure across the whole code base.
      - mgkimsal 14y ago
        One of the arguments/justifications for the PSR standards is to encourage interop of libraries (to be able to mix/match from various frameworks and projects). Standardizing formatting for a team/project is not a bad thing, certainly, but if there's competing styles on a team, but they're making good progress - hitting deadlines, high test coverage, good/deep engagement with stakeholders, etc., code formatting is just not something I'd bother enforcing. It may be a later step to go back during a project post-mortem and get the code ready for 'deep freeze', assuming the project is 'done', but how often does that happen? My perspective is probably a bit different than some here - I freelance, and work in multiple languages for different clients, often concurrently. In a 6 month period I had 2 PHP projects, 2 Grails projects and a Rails project, each running for several months and overlapping. I worked with a different group of people on each project, each with varying skill levels and backgrounds. I adopted my style/technique as best I could for each project, and didn't harp on formatting with anyone, because... it just really doesn't matter. What does bug the heck out of me is someone rechecking out my code, spending time reformatting it, then checking it back in, and counting that as 'work', when there's many many many other issues needing to be worked on.
jasonlotito 14y ago
PSRs where decided based on the most common standards used by some of the biggest PHP projects around. It wasn't a single person setting a standard. PSRs are completely optional. However, you miss the point. The point of this isn't really to define all the options. Rather, it's to spell out best practices (and PSR-0 is really a best practice, and all about interoperability) that the community generally agrees with. Better to have a standard coding style than to have none at all, and if you have to choose one, PSR-1 and 2 are an excellent choice (considering how it was devised).
- stephenr 14y ago
  Im sorry but accepting underscores as a valid alternative to namespaces in 2012, is not a "best practice". The whole concept of PSR-0 is ridiculous anyway, because PHP supports registering multiple class loaders. If a project wants to use a naming convention that won't work with standard spl_autoload(), they can register their own autoloader.
  - phpnode 14y ago
    except if you've ever had to work with lots of different autoloaders at once you'll know that you regularly get conflicts, and getting the correct autoloader order is often a case of trial and error. Using sane conventions across libraries avoids all of this mess.
    - stephenr 14y ago
      i wouldn't call using underscores for namespaces and forced filenames "sane". The built-in spl_autoload offers better support for modern code than the PSR-0 recommended autoloader
      - phpnode 14y ago
        The reason for underscores as namespaces is simply that some older libraries want to maintain compatibility with 5.2X for whatever reasons. Of course it's encouraged that newer libraries are written with proper namespaces and almost all of them are.
anthonyb 14y ago
It does help improve your interoperability with other developers and other code though. Python has had PEP-8 for quite a while now, and it definitely helps in improving both code quality and understanding random libraries that you find on the internet. It doesn't catch everything, but then that's what Pylint is for.

by _ikke_ 14y ago

codeguy 14y ago

I think it's less about being "superior" than standardizing on a common style. Makes it easier to get up and running with someone else's code. But if your team agrees on a common but different style, that's fine too. It accomplishes the same goal. I'm only suggesting the official standard for new PHP developers.

kellishaver 14y ago
Right. I think the main take-away from it is to be consistent and make sure everyone on your team is on the same page about the coding style. I see the PSR as a basic set of good recommendations, rather than something that must be followed. It's a good idea to follow it, but at least follow something. My only complaint with it personally is that I Can. Not. Stand. putting opening brackets on their own line.
- mgkimsal 14y ago
  I understand it's not an either/or situation but... I'd MUCH prefer people spend time writing tests for their code vs debating/arguing/refactoring code style. If your tests and good and coverage is high, there's far less chance I should ever even have to muck around inside your libraries, much less modify them. And again, one doesn't preclude the other, but I see so many people making a bit stink over style - tabs vs spaces et al years before the PSR stuff - yet rarely do I see even 20% of that effort spent on getting people to test. I say this not as someone who tests everything 100%, but as someone who doesn't do much of it, and understands the importance of it. When I'm deciding to use someone else's libraries, I never make a decision based on the code style they've chosen - I base it on maturity, documentation, and tests/examples provided (when there's a choice, sometimes you don't have a choice, or you roll your own). The really good libraries? I never even have to look a their code - it might be all run together on one line for all I care - it just works.
  - kellishaver 14y ago
    If a library works like it should, then you may never have to look at it - that's great. But if you're working on a team, you'll have to read and understand other people's code all the time, and even if you're not, someone, somewhere, is going to eventually want to make that library do something different. I agree that, of the two, good test coverage is more important than pretty formatting, but a good code style is going to make the code easier to debug when those tests fail and easier to extend when the library needs to do more. It's a simple matter adopt a coding style that works and stick with it, so there's really no good reason not to do it. By comparison, it does seem like a trivial thing to obsess over. There are a number of coding styles which are all fine in their own right. I think people should worry less about the specifics and more about the overall intent-to write consistent, clean code. How many blank lines you have after block of code or where you put the opening bracket doesn't really mater in the end, as long as you follow the same structure across the whole code base.
    - mgkimsal 14y ago
      One of the arguments/justifications for the PSR standards is to encourage interop of libraries (to be able to mix/match from various frameworks and projects). Standardizing formatting for a team/project is not a bad thing, certainly, but if there's competing styles on a team, but they're making good progress - hitting deadlines, high test coverage, good/deep engagement with stakeholders, etc., code formatting is just not something I'd bother enforcing. It may be a later step to go back during a project post-mortem and get the code ready for 'deep freeze', assuming the project is 'done', but how often does that happen? My perspective is probably a bit different than some here - I freelance, and work in multiple languages for different clients, often concurrently. In a 6 month period I had 2 PHP projects, 2 Grails projects and a Rails project, each running for several months and overlapping. I worked with a different group of people on each project, each with varying skill levels and backgrounds. I adopted my style/technique as best I could for each project, and didn't harp on formatting with anyone, because... it just really doesn't matter. What does bug the heck out of me is someone rechecking out my code, spending time reformatting it, then checking it back in, and counting that as 'work', when there's many many many other issues needing to be worked on.

jasonlotito 14y ago

PSRs where decided based on the most common standards used by some of the biggest PHP projects around. It wasn't a single person setting a standard. PSRs are completely optional. However, you miss the point. The point of this isn't really to define all the options. Rather, it's to spell out best practices (and PSR-0 is really a best practice, and all about interoperability) that the community generally agrees with. Better to have a standard coding style than to have none at all, and if you have to choose one, PSR-1 and 2 are an excellent choice (considering how it was devised).

stephenr 14y ago
Im sorry but accepting underscores as a valid alternative to namespaces in 2012, is not a "best practice". The whole concept of PSR-0 is ridiculous anyway, because PHP supports registering multiple class loaders. If a project wants to use a naming convention that won't work with standard spl_autoload(), they can register their own autoloader.
- phpnode 14y ago
  except if you've ever had to work with lots of different autoloaders at once you'll know that you regularly get conflicts, and getting the correct autoloader order is often a case of trial and error. Using sane conventions across libraries avoids all of this mess.
  - stephenr 14y ago
    i wouldn't call using underscores for namespaces and forced filenames "sane". The built-in spl_autoload offers better support for modern code than the PSR-0 recommended autoloader
    - phpnode 14y ago
      The reason for underscores as namespaces is simply that some older libraries want to maintain compatibility with 5.2X for whatever reasons. Of course it's encouraged that newer libraries are written with proper namespaces and almost all of them are.

anthonyb 14y ago

It does help improve your interoperability with other developers and other code though. Python has had PEP-8 for quite a while now, and it definitely helps in improving both code quality and understanding random libraries that you find on the internet. It doesn't catch everything, but then that's what Pylint is for.