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 love
to implement this formatting as the rule, but inspection tools like PHPCS
don't recognize this formatting.
i've contended for a long time that the rules in PSR-2 & -12 are
inconsistent, which hurts readability 100% of the time. And it's not just a
"personal feeling" about style and readability. Different structures call
for different usages of operators, control characters, etc. That's the
definition of inconsistency. When i programmed in C# many years back,
Visual Studio pushed really hard on the Allman-8 style described above. It
was jarring at first because i was coming from lazy PHP-land, but i got
used to it and started to understand why it worked so well.
The fact that PSR-2 was based on survey results and what was "most common"
at the time in my mind makes it a horrible standard. There's no rationale,
no explanation why one context should be different from another... It's
just "we always did it this way, so we're always going to do it this way.
Yes, bikeshedding the style isn't an appealing path to take. But the PSR
does exactly that by requiring particular uses of braces, line formatting,
spacing, etc. It seems to me the rules shouldn't be rigid about one set of
rules, but allow for variants. You can keep the legacy formatting if you
want, but allow for alternative rule sets, as long as the *structures* are
built the same way, and the rules within a given project are consistent...
If one project wants to use PSR-2's original style, cool. If you want
Allman-8, awesome. Both styles work, and it shouldn't matter which one is
used as long as it gives continuity to the project.
i realize this line of discussion is confrontational, but this is an
important aspect of community programming, and when a limited set of
people/projects get to determine the course for everyone else, it really
should be fully open to discussion and persuasion. PSR-12 isn't likely to
take any radical changes in its proposed formatting rules, but i contend
that it isn't incompatible with allowing alternate style rules. i really
hope that some of this discussion makes it to the working team, because
right now PSR-12 is little more than a perpetuation of lazy & inconsistent
practices to avoid pushing old projects and developers to sharpen up their
code style.
-jlt
On Monday, 22 April 2019 03:18:30 UTC-4, Mikko Rantalainen wrote:
>
> On Sunday, 21 April 2019 15:48:22 UTC+3, Alexander Makarov wrote:
>>
>> Readability-wise using same braces style as we're using for classes and
>> methods would be beneficial for control structures i.e.
>>
>> if ($foo)
>> {
>> doFoo();
>> }
>> elseif ($bar)
>> {
>> doBar();
>> }
>> else
>> {
>> doSomethingElse();
>> }
>>
>> Clear code blocks, vertically aligned braces.
>>
>>>
>>>>>
> This is basically style called Allman-8 which I'd personally much prefer
> over current PSR style. The Allman-8 is used in many universities teaching
> computer programming because it's probably the most clear way to format
> your code. I see no reason to reduce whitespace from that style and I guess
> nobody is going to argue that they intentionally use hard to follow style
> for teaching.
>
> The only argument against Allman-8 is that it has too much horizontal
> whitespace (tab or 8 space indent for everything) but that's just another
> code smell issue for me. If you feel that 8 space indent is making your
> code too much to the right, the code probably needs splitting to multiple
> methods/functions anyway.
>
> If your only argument for PSR style is consistency, why not switch to
> Allman-8 now instead of waiting for more code to appear which will make the
> switchover even harder? Then you could have have both consistency and
> readability.
>
> --
> Mikko
>
>
--
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/e5465a87-9b76-4d34-89c6-d19aa0f895db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
