By that thinking there's no need for code style standards at all because
the IDE can do all the heavy lifting. Highlighting matching braces is fine,
if they're both on screen. More advanced IDEs go as far as showing you the
opening line when it's out of current view. But in my opinion, that's a
convenience and shouldn't replace the helpful text that immediately tells a
programmer where they are. Ever tried to view code directly on a server
using vi/vim/etc.? It's not quite as easy even with the limited IDE-like
functionality.
If code is already good quality, i totally agree there should be no need
for supplemental comments like those described. But it's not always that
simple.
That said, i think i ultimately agree with Alexander. It doesn't warrant
its own rule or an exception to any rules in the PSR. There are compromises
that can be made, and as suggested, it's a much better decision to do the
cleanup work that would eliminate the need for the extra comments. My
team's style guide uses PSR 1/2/12 as a base, and makes certain
accommodations for legacy code and *coaxing* developers toward better
practices. These end-of comments help us for our purposes, but when we
rewrite this application on a new framework, the expectations for better
code will go way up.
-jlt
On Friday, 29 December 2017 04:28:56 UTC-5, 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 [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/php-fig/2786c78d-96dd-4159-9810-66515755b9b8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
