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/cab85c6e-0c32-454b-9fb2-7a2c9af7d9c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
