look at that and try to find some tutorials. Thanks for
the response.
-jlt
On Monday, 22 April 2019 11:23:04 UTC-4, Josh Bruce wrote:
>
>
> On Apr 22, 2019, at 6:58 AM, Joe T. >
> wrote:
>
> i want my team to comply with code standards, but right now PSR, Symfony,
> an
i wholeheartedly agree with this style. Not only is it *consistent* as the
PSR intends, it's *readable* and makes code-folding in IDEs much cleaner.
i want my team to comply with code standards, but right now PSR, Symfony,
and Zend are the only "standards" supported by most PHP IDEs. i would lov
Hopefully this is just part of the early draft process and more work will
be done to fully detail the already supported functionality to make it part
of the standard. i'd hate to see existing features omitted from the PSR.
That basically means phpDoc has two options:
1. Drop functionality ma
cape($name);
> });
>
>
> I know many developers are used this in some scenarios, but particularly
> when there are many arguments it gets lets readable.
> Also I assume that implementation of auto-formatting allowing this would
> be quite trickier (in fact for example P
Gets my vote. i always enforce a blank line between summary and any
subsequent tags.
On Thursday, 25 October 2018 14:54:51 UTC-4, Woody Gilk wrote:
>
> The PSR-5 recommendation for a summary doesn't make sense:
>
> A Summary MUST end with either
>
>
>- a full stop (.) followed by a line bre
, settling inconsistencies...
Anyway, i'm grateful for this course of action. If there's some way i can
contribute, i welcome the opportunity.
-joe t.
On Tuesday, 15 May 2018 12:51:43 UTC-4, Chris Tankersley wrote:
>
> Hello FIG!
>
> The working group for PSR-12 has decide
i'm not in the WG, but i always restrict to 1 blank line between any two
structures - aside from line after opening *{* and before closing *}* where
no blank line is permitted. Extra blank lines feel like something wasn't
finished. It's just... ew.
-jlt
On Sunday, 22 April 2018 19:52:02 UTC-4,
Agreed! When does *more* than one space (aside from newlines) ever make
sense? i hope these details get resolved...
-jlt
On Sunday, 22 April 2018 20:08:00 UTC-4, Greg Sherwood wrote:
>
> Hi,
>
> I'm working on the PSR-12 standard for PHP_CodeSniffer. I have a question
> about this section:
>
>
s to be going stagnant (or worse, the feedback
ends up ignored), because it was the most "rational" of the style guides i
researched.
-joe t.
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsub
+1000 for this guy. :)
On Monday, 19 March 2018 10:57:06 UTC-4, Alexey Gopachenko wrote:
>
> JetBrains PhpStorm development lead here.
> I would like to participate in PSR-5 (and actually all others) from
> perspective of tool-ability and consistency of introduced features and
> specs.
> I perso
Given the criteria for participation (thanks for clarifying, Larry), i'll
step back from PSR-5 for now so that a group with more direct experience
can be formed. However, i'm still available if any slots remain open.
-jlt
On Saturday, 17 March 2018 12:04:41 UTC-4, Larry Garfield wrote:
>
> On
Given the criteria for participation (thanks for clarifying, Larry), i'll
step back from PSR-5 for now so that a group with more direct experience
can be formed. However, i'm still available if any slots remain open.
-jlt
On Friday, 16 March 2018 18:07:23 UTC-4, Larry Garfield wrote:
>
> When
Looking forward to working on PSR-5 since i missed my chance for 12.
As far as 12 goes, i really do hope some genuine discussion happens for the
inconsistencies and concerns raised by Larry before it's finalized. If no
other reason raised so far makes sense, consider how much simple it would
be
Interest here as well. Basically on stand-by waiting for further
instruction.
-joe
On Thursday, 15 March 2018 14:33:50 UTC-4, Chuck Burgess wrote:
>
> Hey Alice,
>
> I'm slowly trying to form a Working Group in order to resurrect PSR-5.
>
> CRB
>
>
> On Mar 15, 2018 13:28, "Alice Wonder" >
> w
dards" based on majority vote
status quo, or want to go a different direction. If the standard evolves
and the survey is no longer a major contributing factor to its
current/future state, then sure, remove it.
Okay then, back to you guys. Again, apologies if toes were stepped on.
-Joe T.
(Beyond reading the current draft, that is.)
-jlt
On Monday, 12 February 2018 21:17:41 UTC-5, Joe T. wrote:
>
> Chuck,
>
> Sure! i'm new to the WG process, so might need some guidance, but i've
> been working with PHP for 15+ years.
>
> Let me know where i start
Chuck,
Sure! i'm new to the WG process, so might need some guidance, but i've been
working with PHP for 15+ years.
Let me know where i start. :)
-joe
On Monday, 12 February 2018 20:04:45 UTC-5, Chuck Burgess wrote:
>
> At this point, I have a CC sponsor and one WG member.
>
or me.
Thanks. :)
-joe t.
On Monday, 29 January 2018 15:01:25 UTC-5, Chuck Burgess wrote:
>
> I hope to nudge it as close as I can. Part of what stalled PSR5 was much
> contention on how to *add/change* what phpdoc2 could already do.
>
> CRB
> *about.me/ashnazg <http://ab
The short-style syntax does make arrays much more readable, as it no longer
makes them look like function calls.
However, the rule you're referencing is for when you are keeping arguments on
the *same* line. It permits for splitting an array in that signature to
multiple lines, and continuing t
My understanding of PSR-2 (and 12) is only the second one is permitted.
*PSR-12 4.5*
> Argument lists MAY be split across multiple lines, where each subsequent
> line is indented once. When doing so, the first item in the list MUST be on
> the next line, and there MUST be only one argument per
atching { and }
> so I see no practical use in having a comment.
>
> On Tuesday, December 26, 2017 at 10:12:47 AM UTC+3, Joe T. wrote:
>>
>> Refactoring to smaller blocks isn't always practical, particularly with
>> older legacy code. i've often used the style descr
i may be jumping into the end of a resolved discussion, but i'm new in the
group and am looking for opportunities to offer my experiences to the
PSR-12 review process.
*Re: properties first*
i fully support adding a recommendation to define all constants,
properties, and methods declared with t
Refactoring to smaller blocks isn't always practical, particularly with
older legacy code. i've often used the style described, because inevitably,
some hint that describes the block is more helpful than nothing at all. The
project i currently work with is a nightmare of inconsistent patterns,
23 matches
Mail list logo
