Framework: Coding Style Proposal

[GrahamCampbell]

This has been floating around for a long time, so let's put this in writing here.

I propose Laravel does one of the 3 following things:

1. Moves totally to symfony's coding style (possibility without yoda comparisons).

2. Moves to PSR-2 with symfony style (PSR-5) docblocks.

3. Moves to PSR-2 with allman style braces. _Rejected_

---

NB, I vote for number 1. NB, we could still do number 1 without yoda style comparisons if needed.

---

EDIT:

Reading through the comments, it's 100% certain that we should at least move to full PSR-2, and a lot of people seem to like the idea of moving to symfony in the interest of consistency, but without yoda comparisons. Moving without yoda conditions is the only way at the moment anyway since we currently have no automated way to enforce them.

[GrahamCampbell]

Also, I'd be happy to let laravel use my coding style checker to check pulls and every commit pushed for cs. https://styleci.grahamjcampbell.co.uk/. https://github.com/StyleCI. It's actually written using laravel, and uses php-cs-fixer under the hood: https://github.com/FriendsOfPHP/PHP-CS-Fixer.

php-cs-fixer lacks many rules for laravel's current coding style, but includes good rules for symfony and psr-2. I am also working on a fairly complete docblock fixer set: https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/887, and I could write an allman style braces fixer if needed: https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/920.

[driesvints]

1. If you're going PSR-2 then you're going fully for PSR-2 or don't bother at all. Don't mix it with Allman style.
2. Wait for PSR-5 to be finished before deciding on a docblock standard.

[JeffreyWay]

Now that Taylor is full-time, he can knock the remaining PRs out pretty quickly. So switching seems more feasible now - especially as part of L5.

Agree with Dries. Either switch to PSR-2 completely, or don't bother.

[GrahamCampbell]

@driesvints Because we're only using super simple docblock tags, I don't think we really need to wait for the standard to go through, because I honestly can't see them changing. And even if there were minor modifications in the spec, I'll be watching it quite carefully, and will be able to modify the fixers I'm currently writing for php-cs-fixer.

@JeffreyWay Yeh, I want total psr-2 without the other braces too, as I voted for number 1. :)
In terms of the allman style braces - I put them down as a suggestion because @antonioribeiro and @taylorotwell both like that style. I just wanted to see what the response to keeping them would be.

---

But one thing we're agreed on, is to definitely switch to psr-2, the other stuff aside, so that's cool. :)

[Anahkiasen]

:+1: for this. :+1: for this so much. Although I'd either go full symfony or full PSR2 (+PSR5 when available), if we start to mix and match we just swap one complicated CS for another.

[GrahamCampbell]

@Anahkiasen So you vote for number 1 then. NB, symfony essentially uses PSR-5 already.

[Anahkiasen]

Yes option 1. for me. Although I don't agree with _all_ of Symfony's CS (not a fan of yoda conditions) most of it makes sense and it builds on top of PSR2 so, seems like the best option for me.

[GrahamCampbell]

not a fan of yoda conditions

Yeh, me neither. I use symfony cs on all my repos, without yoda conditions, and I also alphabetically sort my imports, and use short array syntax. Symfony's cs currently doesn't require alphabetically sorted imports, and says nothing about short array syntax, other than it can't be used if we support php 5.3 - which laravel doesn't. I think that sort of style would suit laravel too.

[JosephSilber]

@driesvints @JeffreyWay You can pry allman-style braces from my cold dead hands :skull:

[dwightwatson]

I'd like to see PSR-2 with PSR-5 docblocks when ready. I can't see a good reason to follow Symfony's coding style when there's a perfectly good standard to follow.

[lucasmichot]

:+1:

[GrahamCampbell]

There seems to be some confusion here. Symfony's coding style is psr2 with psr5. It just adds a few extra rules on top. It's not something totally different.

[dwightwatson]

That's what I thought, but are there any good reasons for Laravel to adopt those extra rules on top instead of just sticking to the PSR?

[GrahamCampbell]

They allow us to have consistency, instead of having undefined standards, or as we do now, other, different standards on top.

[JeffreyWay]

@JosephSilber I prefer allman braces, too. :)

But I also see value in adopting the standard, and being done with it.

[ibrasho]

Please let this happen... Context switching for minor things like code style is a waste of everyone's precious time.

I'll quote Symfony Coding Standards page:

Remember that the main advantage of standards is that every piece of code looks and feels familiar, it's not about this or that being more readable.

Even though Allman style braces could get a point or two for being more readable, I think sticking to PSR-2 is better in the long term.

Can we compose a list of the additional rules that Synfony uses in addition to FIG CS standards to be able to discuss this better?
http://symfony.com/doc/current/contributing/code/standards.html

[barryvdh]

I'm all for PSR-2, no exceptions. If Symfony is just PSR-2 with some added edge cases, that is probably easier to avoid confusion. So both option 1 and 2 or fine with me :)

[crynobone]

PSR-2 for all laravel/laravel related code, "including generated code" via command line php artisan make:*. For framework, I would think there too much changes in order to swap everything especially since it just one months away from the release.

[barryvdh]

I think @GrahamCampbell was going through all PR's to close as many as possible, so merge conflicts wouldn't be so much of a problem when switching to a new CS. Transforming all the code would probably take some time yeah, even with automated tools.. But it's probably going to have to be now (before L5 reaches stable), otherwise maintaining multiple 5.x with a different CS is going to be even more problematic..

[GrahamCampbell]

@barryvdh, @taylorotwell has been reviewing the pulls, and I've been reviewed the issues.

Transforming all the code would probably take some time yeah, even with automated tools

Not really - php-cs-fixer does a very good job. Especially after my docblock pull request (wip atm).

---

@crynobone Yeh, this proposal applies to all laravel repos, and all "stubs".

[GrahamCampbell]

Can we compose a list of the additional rules that Synfony uses in addition to FIG CS standards to be able to discuss this better?

Look at php-cs-fixer's fixers. They're about 80% complete. And other pull requests and issues on the repo fill another 15%.

[lucasmichot]

@GrahamCampbell whatever the chosen standard, it would be smart to put some control on each PR:

• either in Travis : https://travis-ci.org/thephpleague/omnipay-common/jobs/41626681
• either with a bot providing a style diff/patch to apply, if necessary, as it is done for Symfony

[crynobone]

Not really - php-cs-fixer does a very good job. Especially after my docblock pull request (wip atm).

Yup, but do we have enough time to really test it, could have some side-affect on components especially those that doesn't have good coverage such as database, routing etc

[GrahamCampbell]

either with a bot providing a style diff/patch to apply, if necessary, as it is done for Symfony

I've already suggested a way to do this.

Also, I'd be happy to let laravel use my coding style checker to check pulls and every commit pushed for cs. https://styleci.grahamjcampbell.co.uk/. https://github.com/StyleCI. It's actually written using laravel, and uses php-cs-fixer under the hood: https://github.com/FriendsOfPHP/PHP-CS-Fixer.

[Anahkiasen]

Scrutinizer can check the CS of pull requests and fail if incorrect.

[antonioribeiro]

We using the wrong tools.

Switching to PSR-2 may will be a good thing, but it will also make our code uglier. That may not be a problem to most people, but it is to me and many others, including Eric Allman and even Taylor Otwell.

But why in the hell we keep discussing this whole dam thing, again and again? Because the tools we have are not able to show our code the way we like to see it, and store it the way it would not conflict with others.

If you like to see your code in Symfony style, because it's easier on your brain, why can't you, at the same time I see it in Laravel PSR-2-ish+Allman's? At least in PHP carriage return, spaces and tabs do not affect syntax, so in my humble opinion code could be saved unformatted, to force people to use a proper editor, and displayed in your preferred style. Is this that really difficult? Those same tools are already doing this for Unix and DOS new line, right? So I'll assume it's not. They let us change every single tiny color thingy on interface and code, but forces us to agree on a coding style which is way too far more important than color. That seems very wrong to me.

Could we, please, stop wasting milions of hours discussing tabs vs spaces, braces on next line vs braces on same line..., when, clearly, we will never agree on them?

I vote number 3.

[barryvdh]

Well yes, that is exactly why they agreed on PSR-2, that some think it's pretty, others think it's ugly, but all agree that just using the same CS is a bigger benefit then 'pretty braces'.
So either follow PSR-2 (with correct braces, no exceptions) or don't bother at all.

[driesvints]

@antonioribeiro The problem with Laravel PSR-2-ish+Allman's is this:

It's another new standard we'll have to learn and remember. The whole point of PSR-2 is that it was created by a group of framework maintainers to finally get a standard which they could all adopt and respect. Regardless of yours, Taylor's or anyone's personal preferences, PSR-2 adopts a standard we can all follow and which will give us a universal environment to work in.

The reason I'm pushing so hard for this is because it's a joy for open-source contributors to just go to any large open source project and know that they follow a universal coding standard so you don't have to worry about a project's exceptions or w/e (because there are none). If you don't want to use PSR-2 for your personal/company projects then that's fine but I think we should continue to push large OS projects like Laravel, Symfony, etc to use a common standard.

[GrahamCampbell]

Scrutinizer can check the CS of pull requests and fail if incorrect.

Nah, that doesn't work. Scrutinizer never actually fails the build.

[Anahkiasen]

Even with the new multiple statues update to Github?

[GrahamCampbell]

Yeh, even with that. The issue with scrutinizer is it's already failing anyway.

[GrahamCampbell]

And still showing as green.

[GrahamCampbell]

NB, an example of a pull request using styleci:

[antonioribeiro]

@driesvints, I'm sorry to inform you that, in this particular case, there never be an universal standard. "Compete" and "coding style standard" should never appear in the same sentence. They should not compete, but, as colors, be an option.

The reason is very simple: every single human being is different in taste and 20 (or so) members of a group are not able to tell what some milions will like the most. As I said, it's only good to have a standard because our tools are not smart enough to let us be ourselves. Our brain is constantly evolving, way faster than any coding style will be able to, and forcing it to adapt to someone else's taste is a very good way to slow it down.

@philsturgeon, consider creating a new PSR: Raw File Format for PHP Editors. Adopting editors would save code in this "raw format" and display it in whatever coding style the user like. People would be pleased by looking at the code using their own personal format (PSR-2, PEAR, Zend, Symfony, PSR-2-ish+Allman's), Open Source maintainers would never have to waste time with styling again, people like @GrahamCampbell will be able to focus on more important stuff, end of story.

[GrahamCampbell]

@antonioribeiro That's not really up for discussion here. We are discussing if we should move to either symfony, or just psr-2, and any small variants we might want.

[ibrasho]

I'll quote Symfony Coding Standards page _again_:

Remember that the main advantage of standards is that every piece of code looks and feels familiar, it's not about this or that being more readable.

Sadly, we don't have anything that works as @antonioribeiro suggests, so we still need to follow a standard that is easily referenced. I can't say how much time I wasted just trying to adapt to Laravel Code Style which is not consistent nor documented anywhere AFAIK.

Sure, I might not like every rule in the PSR-1 or PSR-2, but I'm willing to let go of my personal preferences if I know that I won't have to context-switch the way I code when I switch the project I'm working on.

[antonioribeiro]

@GrahamCampbell you are absolutely right, that particular dicussion was moved to https://github.com/php-fig/fig-standards/issues/397.

[GrahamCampbell]

Sure, I might not like every rule in the PSR-1 or PSR-2, but I'm willing to let go of my personal preferences if I know that I won't have to context-switch the way I code when I switch the project I'm working on.

I felt the same when PSR-2 was passed, but I ended up going with it, and it feels quite normal to me now.

[antonioribeiro]

Unfortunatelly this is not good.

_As human beings, we have the blessing and the curse that we're able to adapt to almost anything. No matter how extreme the circumstances you're in, they become normal._
Kevin Powers

[colinodell]

I'm with @barryvdh - either 1 or 2

[mattstauffer]

1 or 2. Probably 2? Consistency over personal style preference for sure.

[reinink]

I'd be VERY happy to see either option number 1 (Symfony) or number 2 (PSR-2), while feel number 3 (Allman) would be a bad move. We all have our personal formatting preferences, but this about consistency and interoperability. Christmas has come late! :christmas_tree: :santa:

[tvbeek]

I think it is important to choose one style and not mixing styles. My experience is that if you start mixing styles you get a mess. Especially for people who start using it. If you use more common standards people will learn it and use it.
In long term it is useful because learning a new coding style will frustrate people who just add a couple of merge request to participate. (Or frustrating reviewers because they have another pr with a bad coding style)

[JosephSilber]

This discussion makes me sad :frowning:

I dislike spaces. I think tabs are better. But I'd gladly use spaces in order to be consistent.

Control flow braces is a different story though. Having them on the same line is simply ugly and less readable. While tabs vs. spaces is just a taste thing, this actually impacts readability.

Every time I work on a PSR-2 project I have to rip my eyes out.

PSR-1 is a very important standard, because it ensures framework interoperability. That's why Laravel adopted it in L4. PSR-2 however has _nothing_ to do with that. Rather, it's about consistency across frameworks (and which some people adopt for their own code).

Since it has no effect on the framework consumers, my opinion is that following PSR-2 is not _that_ important, and we should stick to Allman-style braces. If that means the whole change is not worth the hassle, so be it. We've been doing just fine with Taylor's style till now (occasional hiccups not withstanding - and that wouldn't happen if we go with option 3).

[GrahamCampbell]

The hiccups are not occasional. I spend hours every week dealing with coding standard issues, and it's a total waste of my time.

[Weeblewonder]

Reminder that whatever coding style Laravel itself uses, it's not forcing your domain code to be the same, its still entirely your choice.

However when you're writing PR's for a framework, its your responsibility to respectfully adhere to the guidelines of the person who has to deal with getting it merged (whomever that may be for whatever project).

This shouldn't be a discussion about "but I dont like that one" or "I prefer this one". There are options that you have the opportunity to choose from, any comments should be an "I choose X" or proposing an option that isnt in the list with valid objectionable reasons why it should be considered.

[reinink]

@JosephSilber Out of curiosity, do you use any automated coding standard validation tools, like PHP CodeSniffer? These tools are a dream for businesses and open source projects to help maintain formatting consistency. Since so many people are adopting PSR-2, it only makes sense that a very popular PHP framework, Laravel, follow suite. It simply makes life easier for everyone.

And we don't use PSR-2 because it's perfect and fits everyone's personal formatting choice, but rather because it already has widespread adoption, and tooling built around it.

[antonioribeiro]

And before you, @taylorotwell's time, @GrahamCampbell, but the way things are, there will always be a price to pay. Don't expect a move to PSR-2 to be a life changing situation, having humans dealing with code styling means work to do. Don't expect everyone using things like cs fixer too...

[franzliedke]

Can we all maybe wait until @taylorotwell says whether he even wants to change anything at all?

@reinink This has nothing to do with interoperability, it's only consistency. There's been so much stuff about consistency around here, I'm quite weary of this.

If people would start trying to make their changes consistent with the file they're making changes in, we'd already be much better off. Most people who fail the @GrahamCampbell test don't fail because they're writing PSR-2 compliant code.

[reinink]

@antonioribeiro True, but they don't necessarily need to be using a CS fixer. @GrahamCampbell has already developed tools that fix stuff automatically. Pretty cool stuff he's working on.

[Weeblewonder]

@franzliedke he's already mentioned the only thing stopping him considering adopting a coding standard is because of the amount of open PR's, which is soon to be zero or near zero as he has full time focus on Laravel now.

[reinink]

@franzliedke Fair enough, interoperability is a stretch, although that too depends a little on your definition. As far as code goes, correct, but there is more to a framework than just the code.

[GrahamCampbell]

Just to be clear - moving to symfony and or psr-2/psr-5 will allow laravel to use my automated cs checking tool on pull requests so wouldn't need to review them for cs, the build would be marked as failed, and is clearly separated from our travis test suite.

Yoda style is bad for humans (test cases take care of the issue already)

I agree. I think we should move to symfony without yoda comparisons.

[philsturgeon]

@dereuromark You seem confused on your history.

The original FIG made a mess and made things worse:
E.g. forcing projects like CakePHP to drop consistent bracing and tab indentation for spaces..)

CakePHP chose to switch to PSR-2 on their own.

Spaces as indentation is just wrong (and painful)

Opinions cannot be wrong. The Python community has been using PEP-8 with spaces for years and they haven't exploded.

Yoda style is bad for humans (test cases take care of the issue already)

PSR-2 says nothing about yoda conditionals.

Please, people need to stop talking nonsense about PSR-2 and the FIG. There are a lot of valid pros and cons here but don't make things up.

As @GrahamCampbell says:

The hiccups are not occasional. I spend hours every week dealing with coding standard issues, and it's a total waste of my time.

I too have wasted a lot of time on this. Third party extensions like Dingo are awkwardly forced into following the completely undocumented "Laravel Style Guide", and we then in turn have to help them convert that from whatever coding style they were using, which is normally PSR-2.

Everyone: Please for the love of everything, please stop talking about if you prefer tabs or spaces. The conversation here is so much more important than that one specific choice, and greater than your own specific personal preferences.

[GrahamCampbell]

Spaces as indentation is just wrong (and painful)

No it's not. It makes more sense, as the previous pull with the ridiculous mess of indentation on the constructor proved.

[GrahamCampbell]

please stop talking about if you prefer tabs or spaces

Yeh, moving to psr-2/symfony is about far more than indentation.

[dereuromark]

chose to switch to PSR-2 on their own

We know what's true and what ain't, right @philsturgeon ? Sometimes a PHP community has ways of persuasion.

[GrahamCampbell]

It is still ultimately not the decision of the community. The same is true for Laravel. Taylor will do what he sees as best.

[dereuromark]

Yeh, moving to psr-2/symfony is about far more than indentation.

Sure is.
Just saying that are are alternatives than blindly going down the same path.

[philsturgeon]

I mean if you users asked for PSR-2 a lot then great, but the FIG doesn't have a goon squad of people forcing projects to do shit. I asked @taylorotwell a few times to consider the change, but thats not "the FIG forcing" bla bla bla.

According to my buddies on the team at CakePHP they chose to switch, and its not been a cake walk (ha!) but it's not been utter hell either. It has benefits, it just takes a bit of effort to get there.

The weight off is wether or not putting that chunk of effort in now outweighs the efforts needed to maintain this "Laravel Style Guide" in the future. They could build their own, but that would be terribly wasteful, when PSR-2 covers a lot and the Symfony Style Guide covers a lot more.

Focus on making an awesome framework, and not on fighting for some unique snowflower code style which is better than the rest.

[JosephSilber]

Just realized that PSR-2 forces closure's braces to be on the same line. That's just madness. PSR-2 seems to be inconsistent with itself!

That said, this discussion is not about the pure merits of PSR-2. That ship has sailed. The discussion is about whether it makes sense for Laravel to adopt it (with anything else that might be added on top of it).

Taylor places an _inordinate_ amount of importance on visually pleasing code. He wants people looking at the framework's source code to see it as pleasant on the eye (witness his comment alignment). Braces on the same line are not pleasant to read, so I don't think that fits with Laravel's spirit.

@GrahamCampbell _most_ of your cs reviews are about spaces, not curly brace placement. If you think switching to PSR-2 will vastly cut down on these mistakes that people make, I don't think option 3 would be any different.

[philsturgeon]

Just realized that PSR-2 forces closure's braces to be on the same line. That's just madness. PSR-2 seems to be inconsistent with itself!

@JosephSilber This is not the location for you to learn about PSR-2 for the first time and comment on each thing you spot. Hop on #laravel IRC channel and I can help teach you all about it, but what you're saying has been said a billion times.

[GrahamCampbell]

most of your cs reviews are about spaces, not curly brace placement

That's not true. Given that I'm the one enduring this crap, I've deal with plenty of braces in the wrong place, and I even screw it up sometimes because I'm so used to writing PSR-2 style code.

If you think switching to PSR-2 will vastly cut down on these mistakes that people make

That's not my point, and actually, I think it will. My point is I don't need to personally make the reviews, because my automated tool can report issues on the pull request via the github status api for me.

[philsturgeon]

Also, Scrutinizer config will be drastically simplified from this:

https://github.com/laravel/framework/blob/4.2/.scrutinizer.yml#L4

To this

tools:
    php_cs_fixer:
        config: { level: psr2 }

[GrahamCampbell]

Yeh, scrutinizer isn't a good idea as I've discussed because it doesn't actually fail the build for cs changes. I want the build to fail.

[josegonzalez]

Just here to say that the CakePHP team chose to move to PSR-2 for the following reasons:

• Tired of people complaining our standard was backwards (I prefer egyptian brackets and tabs, but the PSR is the PSR)
• Don't need to maintain our own tooling (like style-checkers or extensions for other packages)
• Simpler for our users to setup their IDEs. Most IDEs and Editors have support for PSR-2, and it's harder to get our own custom stuff in there.
• Easier to switch between projects.

While most of the core was personally against PSR-2 - we all love our tabs - it's better for the community at large to have a consistent coding style. This is why we didn't do half of PSR-2, or pick and choose the bits we want. Just changing part of your coding style will only confuse users.

Here is the lovely issue where everyone lost their fucking minds over how to write their code.

I suggest you guys switch everything to PSR-2 and ignore the holy war. I don't know how you'll PRs after the merge, but I suggest getting them to a minimum or teaching the committers how to manually merge them in.

[antonioribeiro]

@GrahamCampbell Can't your automated tool support Laravel own standard? Laravel is not that far from PSR-2.

Laravel (probably) follows - correct me if I'm wrong

Code MUST follow a "coding style guide" PSR [PSR-1].
There MUST NOT be a hard limit on line length; the soft limit MUST be 120 characters; lines SHOULD be 80 characters or less.
There MUST be one blank line after the namespace declaration, and there MUST be one blank line after the block of use declarations.
Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.
Opening braces for methods MUST go on the next line, and closing braces MUST go on the next line after the body.
Visibility MUST be declared on all properties and methods; abstract and final MUST be declared before the visibility; static MUST be declared after the visibility.
Control structure keywords MUST have one space after them; method and function calls MUST NOT.
Opening parentheses for control structures MUST NOT have a space after them, and closing parentheses for control structures MUST NOT have a space before.

Laravel does not follow

Code MUST use 4 spaces for indenting, not tabs.
Opening braces for control structures MUST go on the same line, and closing braces MUST go on the next line after the body.
Opening braces for classes MUST go on the next line, and closing braces MUST go on the next line after the body.

Which also shows that we are basically talking about spaces and braces here. Yes the conversation is much more than that, but we are still talking about cosmetics being consistent between frameworks, and being able to autocheck for cosmetics, it's not like your code will not compile or anything like that.

I did some changes to be able to use CodeSniffer with Laravel code, not very far from something usable: https://github.com/antonioribeiro/laravelcs

[GrahamCampbell]

Can't your automated tool support Laravel own standard? Laravel is not that far from PSR-2.

No, sorry. I don't have the time to write a more fixers. The current fixers took multiple people years to write in total.

[JosephSilber]

@antonioribeiro Laravel's classes currently don't put their braces on the next line.

[GrahamCampbell]

Yeh, but they will do. I'm pretty sure Laravel will be moving to PSR-2. We're just discussing any additional standards we want to apply too.

[JosephSilber]

@GrahamCampbell I was just replying to this.

[Anahkiasen]

Here is the lovely issue where everyone lost their fucking minds over how to write their code.

Holy wow, people will really disagree with anything.

[bcrowe]

@GrahamCampbell You might want to check out https://github.com/squizlabs/PHP_CodeSniffer's phpcbf tool. It pretty much covers all the missing bits of PSR-2 fixers that PHP-CS-Fixer is missing (multi-line function fixer, etc etc). It helped us greatly with moving CakePHP over to PSR-2.

[GrahamCampbell]

@bcrowe I'm aware of that "other tool". But I have a loyalty to php-cs-fixer, and am already working on more fixers for them.

[nesl247]

Honestly, PSR-2 is the only logical answer in my opinion. If we are going to look to FIG to be the standards body for PHP, then we need to use the standards. Picking and choosing what a project follows and what doesn't just leads to everything being different. Rather than being able to just contribute code, you need to go read a style guide for each project.

Python solved this with their PEP-8. From the documentation on it, even they admit it evolves over time. Stick with PSR-2, and if changes to PSR-2 are wanted, submit requests to have PSR-2 changed.

[bcrowe]

@GrahamCampbell Awesome. Looking forward to seeing them.

[GrahamCampbell]

@bcrowe https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/887 is the big one at the moment. I have written some other fixers currently in the tool too. https://github.com/FriendsOfPHP/PHP-CS-Fixer/graphs/contributors.

[patrickheeney]

Stick with PSR-2, and if changes to PSR-2 are wanted, submit requests to have PSR-2 changed.

:+1:

[philsturgeon]

If oddities in PSR-2 are discovered then we can absolutely try to get some errata added. I've done it twice before, and Taylor is a voting member in the FIG which will help.

[hipsterjazzbo]

FWIW, I'm not a huge fan of a few different parts of the PSRs, but I would LOVE to to see 1 happen.

[philsturgeon]

We’ve established that not 100% of people are 100% happy with 100% of the PSRs. :)

[hipsterjazzbo]

Yeah sorry, I was just trying to re-re-re-iterate that standard > individual preference.

[philsturgeon]

Perfect! :)

[sdebacker]

PSR-2 ! (or I move to CakePHP)
I vote for number 1.

[tomschlick]

I personally hate opening brackets on the same line as the method declaration but if adopting PSR-2 means we finally have a real standard I'm all for it.

[bkuhl]

I'd vote symphony then PSR-5. No Yoda comparisons.

[bcrowe]

@tomschlick Opening braces for methods are on the next line: https://github.com/php-fig/fig-standards/blob/master/accepted/PSR-2-coding-style-guide.md#43-methods

[tomschlick]

@bcrowe you're right, i meant the if structure statement not method declarations.

[GrahamCampbell]

I'll add a summary to what the common opinion is in my op...

[KennedyTedesco]

I'm all for PSR-2.

[kaidesu]

PSR-2 all the way (and then PSR-5).

[rapliandras]

+1

[GrahamCampbell]

I think it the best idea would be to do PSR-2 and PSR-5, and have some symfony rules as informal style requirements, but not required to fail a build.

[bkuhl]

I'd be against anything conditional as it'll just create inconsistency.

On Wed Dec 31 2014 at 6:42:21 AM Graham Campbell [email protected]
wrote:

I think it the best idea would be to do PSR-2 and PSR-5, and have some
symfony rules as informal style requirements, but not required to fail a
build.

—
Reply to this email directly or view it on GitHub
https://github.com/laravel/framework/issues/6836#issuecomment-68437405.

[GrahamCampbell]

Ok. The trouble with symfony is some areas are a bit blurry. Like, I've written some symfony level fixers for php-cs-fixer, which is the official fixer used by fabbot.io, but then some other people are using "symfony" rules for phpcs, and they're not always identical.

[joecohens]

I vote for option 3. PSR-2 for CS and Allman style braces to keep it laravelish way.

[barryvdh]

Just to clarify: PSR-2 with Allman style braces is NOT PSR-2, so option 3 should probably be:

1. Move to something similar to PSR-2, but with Allman style braces instead of PSR-2 style braces.

And while I do like the argument, the outcome wasn't rather surprising (as PSR-2 has been asked a lot), but still no word from Taylor. So @GrahamCampbell this is really something that is considered, or are we just hoping to convince Taylor with this topic?

[GrahamCampbell]

@barryvdh We're not doing option 3 anyway. It's pretty much between 1 and 2 atm.

[nmabhinandan]

IMO PSR-2 is more readable and comfortable. But I do agree with @ibrasho . This blog post by Yossi Kreinin flashes light some psychological aspects of coding standards.

http://yosefk.com/blog/coding-standards-is-consistency-prettier-than-freedom.html

[joecohens]

Just to clarify: PSR-2 with Allman style braces is NOT PSR-2, so option 3 should probably be:

In this case I change my vote for option 1.

@GrahamCampbell Can we mark the third option on the original question a has "del"?

[GrahamCampbell]

Yeh, I'll update the op...

[jwpage]

If Laravel moves to the Symfony standard, will this include the naming conventions (such as Trait/Interface suffixes) as well, or does this issue only relate to code structure?

[GrahamCampbell]

No. Those suffixes don't make sense for laravel.
On 3 Jan 2015 08:56, "Johnson Page" [email protected] wrote:

If Laravel moves to the Symfony standard, will this include the naming
conventions
http://symfony.com/doc/current/contributing/code/standards.html#naming-conventions
(such as Trait/Interface suffixes) as well, or does this issue only relate
to code structure?

—
Reply to this email directly or view it on GitHub
https://github.com/laravel/framework/issues/6836#issuecomment-68588038.

[nmabhinandan]

I think, unless Taylor makes a "Laravel Style Guide", PSR-2 is our best bet!

[RomainLanz]

I really don't like Allman Brace, but it's not the meaning of this issue.
I think move to PSR-2 and then PSR-5 is the best idea. I don't if using Symfony standard is really useful for Laravel.

[GrahamCampbell]

Symfony is psr2 and psr5 btw. It just adds some extra rules.

[GrahamCampbell]

Anyway, thanks for your input guys. I'll close this for now, and I'll have a chat with Taylor at some point.

[TomasVotruba]

How did this evolve? I would like to help to create Laravel coding standard repo

[browner12]

@TomasVotruba https://laravel.com/docs/5.4/contributions#coding-style

[GrahamCampbell]

Laravel's code style is also documented at https://styleci.readme.io/docs/presets#section-laravel.

[TomasVotruba]

Anything automated and reusable for other repositories?

[GrahamCampbell]

Anything automated and reusable for other repositories?

Yeh. Absolutely. You can pull in the Laravel preset on StyleCI. In fact, thousands of repos already do. :)

[TomasVotruba]

Thanks! Any simple example for that?

How can I fix my coding style locally? E.g. not published on GitHub yet.

[browner12]

lots of IDEs will have presets for coding styles. I would start there.

[TomasVotruba]

That's not easy to replicate since locked to 1 personalized program.

So there is nothing like:

vendor/bin/laravel-cs fix src

[barryvdh]

Just use PSR-2 for your coding style. That has presets everywhere.

[TomasVotruba]

I bet there are many extra rules than PSR-2 in Laravel, like in @Symfony set in PHP-CS-Fixer. That's what I'm looking for.

I'm surprised nobody made such package yet.

[hannesvdvreken]

We tried but php-cs-fixer is not that extendible that you can define your own preset like @something.

[TomasVotruba]

@hannesvdvreken Have you tried config approach like in .php_cs like in repo of PHP-CS-Fixer?
There you can specifiy all the fixers you need.

Then call it in another package like this:

vendor/bin/php-cs-fixer fix src --config vendor/laravel/coding-standard/.php_cs

[Anahkiasen]

No we went with a wrapper package as we needed some extra logic

[0xb4lint]

I've created a PR with @Laravel rule set for PHP-CS-Fixer: https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/2985
I understand the StyleCI does it's job, but I think it's essential to Laravel based projects which are not using StyleCI.
Feel free to contribute.

[GrahamCampbell]

Easier to just use StyleCI. Fixing as a service, and, more importantly, up to date rules as a service. :P

[0xb4lint]

@GrahamCampbell Why we can't just use both (optionally the PHP-CS-Fixer)?
(What about private repos?)
It think it's a good starting point for newbies (with IDE integration).

[GrahamCampbell]

What about private repos?

StyleCI supports those too.

Why we can't just use both (optionally the PHP-CS-Fixer)?

You can, but the config mapping from StyleCI to PHP-CS-Fixer is both proprietary, and actually, only partial. You can't just do a 1-1 map. I know of a GitHub project that attempts to do this, but it doesn't work well.

[TomasVotruba]

@valentinxxx I agree with you, mainly for usability and adaptability reasons.

I consider this much easier for entry:

composer require <tool>
vendor/bin/<tool> fix --rule=@Laravel 

No matter if it is public or private project.

[keradus]

StyleCI is basically a wrapper over PHP CS Fixer with few additions.
Asking ppl to rely on web-service and not running tool locally is not nice, imagine same approach for tests - statement that one shall rely on Travis/CircleCI/AppVeyor/... and not run PHPUnit/Behat/... locally at all is extra sad

[TomasVotruba]

@keradus Well written, I share the view with you.

[GrahamCampbell]

Asking ppl to rely on web-service and not running tool locally is not nice

That's fine. I'm just saying someone needs to take responsibility for updating the mapping. StyleCI's maintainers will not be doing that.

[GrahamCampbell]

StyleCI is basically a wrapper over PHP CS Fixer with few additions.

Yeh, that's true. We're not claiming we don't do that for PHP code. :P

[GrahamCampbell]

In recent times, the difference between StyleCI and PHP-CS-Fixer is getting smaller and smaller. The main difference left at this point, is just config.

[keradus]

Yeh, that's true. We're not claiming we don't do that for PHP code. :P

I remember originally StyleCI provides information it's built on top of PHP CS Fixer. I cannot find it now.

[GrahamCampbell]

We're not claiming that we don't. That's not the same as explicitly saying that we do.

[keradus]

You did say it explicitly one day. Now you don't. Sad for a service that's basically a big wrapper.
Even with every update you just take changelog of PHP CS Fixer.

[0xb4lint]

I see this is a very sensitive area for you guys, I just want to create a @Laravel ruleset for this great tool. As I stated before this is a very convinient way for using Laravel-like coding style on private stuff (e.g. projects without git 🙈)

(Btw. I think it's out of topic 😶 https://gjcampbell.co.uk: ...StyleCI is powered by PHP CS Fixer...)

[CupOfTea696]

What I'm still wondering is why Laravel adopted string concatenation with no spaces (e.g. 'hello'.'world') instead of with spaces (e.g. 'hello' . 'world'). I find the second one way more readable and I don't believe PSR-2 has rules for that?

[browner12]

because it's all made up, and the points don't matter!

[Anahkiasen]

No but the spaces do :p

[philsturgeon]

There's nothing about that in PSR-2. As a friendly word of warning, this thread would be a poor location to open up the can of worms that is raising (dis)agreements with arbitrary style choices made by Laravel on top of PSR-2.

Lots of mud and weeds to get stuck in down that road.

On Aug 21, 2017, at 12:12, Sven Wittevrongel [e-mail] wrote:

What I'm still wondering is why Laravel adopted string concatenation with no spaces (e.g. 'hello'.'world') instead of with spaces (e.g. 'hello' . 'world'). I find the second one way more readable and I don't believe PSR-2 has rules for that?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.