|
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. |