Seeking Explanations of PRS-2 Standards

[Spencer Hill]

I'm new to PHP-FIG and this Group, forgive me if this is not the appropriate place to post my question.

I come from a WordPress background - I'm sorry - haha. After reviewing the PSR-2 standards I found myself with a lot of questions beginning with "Why?" and struggling to find explanations.

Ex. Why CamelCase over_underscores when _ have less "cognitive friction"?

Ex. Why a blank line at the end of PHP documents?

Ex. Why curly brace on it's own line for classes and functions?

All of these things seem illogical to me and I would have never thought to do them naturally. So I'm surprised they're standards. But, looking at the list of Members in PHP-FIG I have to assume there are well-thought reasons for this that don't come down to opinion. Could anyone educate me?

Thank you all for your time!

[Christopher Pitt]

Hey Spencer,

To answer these why's, the team behind PSR-2 did a survey of commonalities amongst PHP frameworks: http://www.php-fig.org/psr/psr-2/#appendix-a-survey

Kind regards

Chris

[Spencer Hill]

Thanks for the reply Christopher! So, are you saying that basically what this survey revealed as used most often is what was adopted as the standard? Or was this just showing what was common and then discussion about reasoning for those practices went from there? Thanks for your time!

--
You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/y4ZKrsHMWXY/unsubscribe.
To unsubscribe from this group and all its topics, send an email to php-fig+u...@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/47b838f4-b96a-4938-bfb7-2bf603770248%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ahmad Samiei]

Re: Ex. Why CamelCase over_underscores when _ have less "cognitive friction"?

Both are easy to parse and easy to read.
camelCase is easier and faster to type (also less chars)

Re: Ex. Why a blank line at the end of PHP documents?

Definition of a line in POSIX standard:

3.206 Line: A sequence of zero or more non- <newline> characters plus a terminating <newline> character

Otherwise, some programs might have problems processing the last line then.
Many editors and tools (ex. git) show a warning message if there is no newline at the end of file.



Re: Ex. Why curly brace on it's own line for classes and functions?
Opening braces for classes/methods MUST go on the next line, and closing braces MUST go on the next line after the body.

If you mean why on the next line? Because it's more readable.
It gives grouping feeling for class/method body.
It keeps parameters list separate and more obvious.

    public function methodName(
        $callable,
        $request,
        $response,
        $routeArguments
    ) {
        $bodyParam = ...
    }

    public function methodName(
        $callable,
        $request,
        $response,
        $routeArguments) {
        $bodyParam = ...
    }

Ancient standards had different reasons to not recommending the most readable style. (ex. computers display was small, storage limitation, printer and paper tape etcetera.. )

[Christopher Pitt]

The survey showed what was common, which became what was standard, as I recall.

[Paul Dragoonis]

Used most used (the commonalities) between the frameworks and major libraries at the time.

Cognitive load for switching between these frameworks and providing a level of consistency between them. 

Phpstorm has an auto formatter to format your code for you, so even if its not natural to you it will format it for you. Phpcsfixer does the same.

On 24 Jan 2017 03:18, "Spencer Hill" <thespen...@gmail.com> wrote:

Thanks for the reply Christopher! So, are you saying that basically what this survey revealed as used most often is what was adopted as the standard? Or was this just showing what was common and then discussion about reasoning for those practices went from there? Thanks for your time!

On Mon, Jan 23, 2017 at 6:18 PM Christopher Pitt <cgp...@gmail.com> wrote:

Hey Spencer,

To answer these why's, the team behind PSR-2 did a survey of commonalities amongst PHP frameworks: http://www.php-fig.org/psr/psr-2/#appendix-a-survey

Kind regards

Chris

--

You received this message because you are subscribed to a topic in the Google Groups "PHP Framework Interoperability Group" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/php-fig/y4ZKrsHMWXY/unsubscribe.

To unsubscribe from this group and all its topics, send an email to php-fig+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/47b838f4-b96a-4938-bfb7-2bf603770248%40googlegroups.com.
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+unsubscribe@googlegroups.com.

To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/CAM7kXxcHqywt8t-zNmn%3DzgavwsMDEPz4NXsXVn828iP6iC17qg%40mail.gmail.com.

[Jason Judge]

On Tuesday, 24 January 2017 03:25:36 UTC, Ahmad Samiei wrote:

...

Re: Ex. Why a blank line at the end of PHP documents?

Definition of a line in POSIX standard:

3.206 Line: A sequence of zero or more non- <newline> characters plus a terminating <newline> character

Otherwise, some programs might have problems processing the last line then.
Many editors and tools (ex. git) show a warning message if there is no newline at the end of file.

 
Based on this definition, a blank line has zero non-<newline> characters before its terminating <newline>. So that means a PHP file must end with TWO sequential <newline> characters in order to end the file with a blank line.

However - that was never the intention of that PSR statement. There is NO need to put a blank line on the end of each PHP script, in fact you MUST NOT have a blank line. You just need to make sure the file consists of *lines* according to the POSIX standard, and that the last line is NOT blank. It's misleading, and hopefully the replacement for this recommendation will make it clearer.

The confusion came from what people *think* they are looking at when viewing a script in their favourite editor, rather than how the file is really constructed.

-- Jason

[Chuck Reeves]

Back in my day, if you had more than one blank line after a closing PHP and tried to start a session, you would get an error stating the headers were already sent.  This was because the parser would strip out one blank line only.  by forcing it in a standard, it would help prevent such silly mistakes when some one is using your lib.

[Murks vom Gurk]

Imho using camel/upper-lower-mix,  _ or whatever in identifiers to get an itsy bitsy better readability is a nasty habit unless there is a compiler, IDE, 100% coverage unit tests of whatever that will force you to keep spelling identical everywhere. Ppl do it in PHP just because they are used to it from compiler languages like java or c++ - but for PHP code - no rationale behind it at all.

Best practice for PHP (identifiers are case sensitive!): Standard stuff (methods, variables, class names...) all lowercase, constants and special stuff all uppercase = no misspellings = no problems at runtime.

Making a (for the sake of the standard completely unneccessary) bad practice mandatory just because it's widely spread in the wild - doesn't make sense to me. :p

[Woody Gilk]

The goal of PSR-2 is to have a consistent style across most PHP projects. The style chosen was, for the most part, already used in the FIG member projects. The PSR-2 rules have done a fantastic job in providing a standard code style that allows me to jump into any PHP code base and be immediately familiar with how to write code for that code base.

Of course code style will always be subjective but having a consistent style is better than having to adapt to each specific project's style.

--
Woody Gilk
http://about.me/shadowhand

--

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+unsubscribe@googlegroups.com.
To post to this group, send email to php...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/php-fig/f4c14055-b80b-46a5-9fb6-62f8d17dc4dd%40googlegroups.com.