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 is important in practice - but still something to keep in
mind/think about, IMO.
On Wed, May 16, 2018, 01:59 Alice Wonder <alicedomblog...@gmail.com> wrote:
> 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 solve what is a distraction for some creates a required distraction
> for others over something that either party could easily adjust to their
> own preference with phpcs when working on someone else's code.
>
> On Wednesday, May 16, 2018 at 12:42:47 AM UTC-7, Alessandro Lai wrote:
>>
>> 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 maggio 2018 09:26:17 UTC+2, Alice Wonder ha
>> scritto:
>>>
>>> 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 at end of a
>>> closing bracket. Why does it matter to them?
>>>
>>> On Friday, December 29, 2017 at 1:28:56 AM UTC-8, Alexander Makarov
>>> wrote:
>>>>
>>>> Any good IDE and even simple code editors could highlight matching {
>>>> 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 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, procedural logic crammed into class methods, etc. Just getting
>>>>> things documented to understand inner workings of individual *blocks*
>>>>> (let alone whole functions) has been a long, slow process.
>>>>>
>>>>> That said, perhaps moving the "end-of" comment to the line *inside*
>>>>> or *after* the terminating *}* can be helpful in most cases, but not
>>>>> perfect.
>>>>>
>>>>> }
>>>>> // END foreach($rows)
>>>>> }
>>>>> // END while ($count)
>>>>> // END ridiculously large if ($foo)
>>>>> } elseif ($bar) {
>>>>> // ...
>>>>> }
>>>>> // END ridiculously large if/elseif chain
>>>>> // END of foo()
>>>>> }
>>>>> }
>>>>>
>>>>> There's no ideal solution, given other rules about splitting chained
>>>>> controls like "*} else[if ()] {*" because there's no good placement
>>>>> of such a comment, nor good way to format it if complying with all the
>>>>> rules.
>>>>>
>>>>> On Sunday, 3 December 2017 05:07:03 UTC-5, Andreas Möller wrote:
>>>>>>
>>>>>>
>>>>>> I have a style that includes commenting on closing braces of long
>>>>>> blocks to help readability. For example,
>>>>>>
>>>>>> class MyClass
>>>>>> {
>>>>>> ...
>>>>>> } // MyClass
>>>>>>
>>>>>>
>>>>>> How about not writing long blocks to help with readability?
>>>>>>
>>>>>> There are a range of possibilities to refactor your code to avoid the
>>>>>> need for comments altogether. See https://refactoring.com/catalog/.
>>>>>>
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Andreas
>>>>>>
>>>>> --
> You received this message because you are subscribed to the Google Groups
> "PHP Framework Interoperability Group" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to php-fig+unsubscr...@googlegroups.com.
> To post to this group, send email to php-fig@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/d6dffd82-8657-4410-a6ae-79f13373b849%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/d6dffd82-8657-4410-a6ae-79f13373b849%40googlegroups.com?utm_medium=email&utm_source=footer>
> .
> For more options, visit https://groups.google.com/d/optout.
>
--
You received this message because you are subscribed to the Google Groups "PHP
Framework Interoperability Group" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to php-fig+unsubscr...@googlegroups.com.
To post to this group, send email to php-fig@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/CAFjuE%2BmfnSSHVy7J7b3rYHUdnASMp168JzEEmNKoesoUXBmStg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
