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
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 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
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ì
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
With my original query, I was never suggesting that the closing comments be a
part of the PSR, I was merely questioning the “MUST NOT” mandate which seemed
overly restrictive. It complicates using the PSR as a foundation for standards
that could be derived from it (should they prefer the style
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
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
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,
> 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
Section 4 states, "Any closing brace MUST NOT be followed by any comment or
statement on the same line."
I have a style that includes commenting on closing braces of long blocks to
help readability. For example,
class MyClass
{
...
} // MyClass
The section 4 statement disallows this
11 matches
Mail list logo
