Thanks for the clarrification.
I'll echo Stefano's thoughts and say that referring to a previous section
is generally helpful when the standard is being heavily modified (you don't
want to update 10 places each time), but duplicating those rules once the
standard moves to review seems like the
While I disagree with this specific part of the standard, having it in
there at least means a decision has been made and code will be more
consistent for it. Coding standards should be opinionated, and I think
PSR-12 needs more rules and not less.
Greg
On Wednesday, 16 May 2018 18:08:50 UTC+10
TBH making readers to jump to another section that contains different
informations is kinda lazy.
Can we just copy paste the relevant indications and do without the
reference to the closures?
Il giorno mer 16 mag 2018 alle ore 17:44 'Alexander Makarov' via PHP
Framework Interoperability Group ha
1. The opening brace MUST go on the same line, and the closing brace MUST
go on the next line following the body.
On Tuesday, April 24, 2018 at 1:53:06 AM UTC+3, Greg Sherwood wrote:
>
> Hi,
>
> I'm working on the PSR-12 standard for PHP_CodeSniffer. I have a question
> about this section:
>
>
Yes indeed, and we have been discussing the open PRs so far.
Trying to nudge the WG formation formality along is just an
"administrative" task that this email was attempting to nudge along 😁 ...
pinging from the PR itself has been ineffective, so I thought a dedicated
email might help.
CRB
On Wed
This last point feels like an agreement for not having a coding standards
PSR at all... "Just preprocess all the code you ever work with so it
follows whatever style you personally prefer" is pretty much where we
started before PSR-2. Not something I disagree with, mind - that kind of
flexibility i
I guess that's fine. It's just a recommendation, I can choose to ignore
that part of it in my own code.
Just a note though - I don't use an IDE, many people do not.
And while the matching opening { is highlighted, when I have to look up to
see it it distracts my mind from what I'm doing.
So to
The sponsor, which in this case should be Michael, has to call the vote on
that. When the vote passes, the WG is officially formed.
In any case, that shouldn't stop you from working on the draft anyway, as
the content of it shouldn't matter in regard of the vote, which is only
about the willingn
The PSR will follow its normal course: the WG has already discussed a few
thing that are needed to be fixed, and appropriate PRs will be submitted.
After that, a new review vote will be held, and the PSR will go back into
review phase.
Il giorno mercoledì 16 maggio 2018 05:42:24 UTC+2, Adrien C
We discussed that as WG, and we concluded that having a comment in the same
line of a closing bracket can hinder readability, due to the fact that the
closing bracket could not be seen; also, not only IDE but basically any
code editor (even vim) have bracket highlighting.
Il giorno mercoledì 16
Hi Mark, and thank you; also, welcome Anton!
I've updated the personnel list, can you confirm to me that that is
correct, so I can push it to the official site?
Il giorno martedì 15 maggio 2018 19:04:18 UTC+2, Ben Marks ha scritto:
>
> Hi all,
>
> Effective immediately the representative for Mag
I do not use an IDE. I do not like them.
Typically the only comments I put at the end of a bracket is for end of
class and end of function. End of class is not needed when the file only
contains a class, but it provides visual consistency.
I'm not sure why some people care if there is a comment
12 matches
Mail list logo
