[PSR-12] <?php declare(strict_types=1) should be on same line in all cases

3,016 views
Skip to first unread message

Michael Sheakoski

unread,
Dec 2, 2016, 10:56:49 PM12/2/16
to PHP Framework Interoperability Group
Dear FIG,

In https://github.com/php-fig/fig-standards/blob/d8e761e20a14112f6d209c8f719e2960af4ca3b2/proposed/extended-coding-style-guide.md there are 3 different examples of declare(strict_types=1): one directly below <?php, another several lines below the <?php after a doc block, and another on the same line.

Please consider a single standard of putting declare(strict_types=1) on the same line as <?php for consistency across PHP-only and HTML+PHP files. It is much clearer to the developer that this file is running a special mode of PHP, not the usual non-strict mode, and they don't need to scan around doc blocks and namespace declarations to figure that out.

<?php declare(strict_types=1);

use Foo\Bar\Baz;

class Thing extends Baz
{
}

Best regards,
Michael

Woody Gilk

unread,
Dec 3, 2016, 12:39:47 AM12/3/16
to PHP Framework Interoperability Group
I disagree with this suggestion. There should be two cases:

1. For mixed HTML/PHP files, the first line should be:

<?php declare(strict_types=1); ?>
...

2. For pure PHP files, the first lines should be:

<?php

declare(strict_types=1);

...

This is consistent with current standards regarding namespace, use, and class declarations.

--
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/6a81f1f0-f2b7-4429-9cf7-4cfe4db7768d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Rudolph Gottesheim

unread,
Dec 4, 2016, 4:28:48 AM12/4/16
to PHP Framework Interoperability Group
I think strict mode will be the default for the majority of developers. (At least for the kind that cares about PSRs.) So pretty much every PHP file you encounter will have those extra lines at the beginning. Also, I think the single line version looks more "Settings for this file" and the multi-line one like "here's the first statement of this file."

So I'm for a single version in all cases: <?php and declare() on the same line.

Michael Mayer

unread,
Dec 4, 2016, 8:48:36 AM12/4/16
to PHP Framework Interoperability Group
I disagree too.

What, if PHP8 will introduce a new execution directive and PHP9 as well etc. And all of these are considered as good practice.
Where should I put them? All in the same line?

<?php declare(strict_types=1); declare(php8_directive=1); declare(php9_directive=1);


use Foo\Bar\Baz;

class Thing extends Baz
{
}

Ewww!

Best regards,
Michael Mayer

Jordi Boggiano

unread,
Dec 4, 2016, 12:50:55 PM12/4/16
to php...@googlegroups.com
I'm with Rudolph on this one, as I replied in the survey that was sent a
while back. IMO it should be on the first line to make sure it's visible
and not missed because it is such a meaningful line. It completely
changes the way the engine works, it's not php anymore, but strict php,
and you better be aware of it.

As for the fear that more flags will be added, well of course it's
possible but IMO unlikely. In any case we can revisit that topic if
needed when we have more flags, I don't think we need to set the rule of
today based on future unknowns.

Cheers
> --
> 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+u...@googlegroups.com
> <mailto:php-fig+u...@googlegroups.com>.
> To post to this group, send email to php...@googlegroups.com
> <mailto:php...@googlegroups.com>.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/php-fig/07f36815-e178-42ee-b76c-42fa446fbfd9%40googlegroups.com
> <https://groups.google.com/d/msgid/php-fig/07f36815-e178-42ee-b76c-42fa446fbfd9%40googlegroups.com?utm_medium=email&utm_source=footer>.
> For more options, visit https://groups.google.com/d/optout.


--
Jordi Boggiano
@seldaek - http://seld.be

Michael Mayer

unread,
Dec 4, 2016, 2:01:09 PM12/4/16
to PHP Framework Interoperability Group
But we already have today:

declare(encoding='ISO-8859-1');
declare(ticks=1);

And for both holds: the file is running a special mode of PHP, not the usual one.
– Should I write all of them in the first line, or is strict_types such special?
– And, if so, what makes it such special?

Furthermore, at least for ticks, I see valid multi-line use cases:

Block declare statements are allowed and MUST be formatted as below. Note position of braces and spacing:
declare(ticks=1) {
   
//some code
}

Moreover:

 Each block MUST be in the order listed below, although blocks that are not relevant may be omitted.
  • File-level docblock.
  • One or more declare statements.
  • The namespace declaration of the file.
Hence, I know where they are, and I don't need to scan around doc blocks and namespace declarations.

Sorry, but I cannot see at the moment, how a consistent style recommendation may look like with that change.
However, I understand that declare statements are more important than the File-level docblock – thus why
not move them to the top of the list instead?

Best regards,
Michael Mayer

Michael Sheakoski

unread,
Dec 4, 2016, 5:52:05 PM12/4/16
to PHP Framework Interoperability Group
Michael Mayer, I think your suggestion sounds like a good idea. My main point originally was to keep the declare() statements close to the <?php because they change how the language works. An example of what your suggestion might look like:

<?php
declare
(strict_types=1);
declare
(encoding='ISO-8859-1');
declare
(ticks=1);

/**
 * Hello. I am a file-level DocBlock.
 * I hope you are enjoying the example.
 */


use Foo\Bar\Baz;
use InvalidArgumentException;

/**
 * Class Thing is a wonderful class,
 * the best class.
 */

class Thing extends Baz
{
   
...
}

I left the <?php and declare() statements touching because I feel that they're closely related, but a blank line between other blocks should still remain. What does everyone think?

-Michael

Korvin Szanto

unread,
Dec 4, 2016, 6:27:51 PM12/4/16
to PHP Framework Interoperability Group
Hi All,
This is something that we polled with the survey. At this point we are still waiting for some member replies but I can tell you that by and large things were pretty unanimous. As far as this specific issue, it looks like 94% responded with no objections and 2/3rds of responses preferred the status quo of declare on the next line. Because of that data and because of the subjective nature of this issue, we're probably unlikely to take further discussion into serious consideration unless there's a new argument that we haven't discussed before.

Thank you all for paying such close attention, I really appreciate you keeping the discussion and excitement going while we work to get this wrapped up. I plan to collect the remaining member replies and post some results with a plan moving forward sometime this week.

Best wishes,
Korvin

To unsubscribe from this group and stop receiving emails from it, 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/6966a531-618d-4c2a-9236-2b97f5a2c78f%40googlegroups.com.

Rudolph Gottesheim

unread,
Dec 5, 2016, 7:06:43 AM12/5/16
to PHP Framework Interoperability Group
So the section will be updated to enforce one specific style? I still would have liked the same-line style better then the other, but I think any recommendation is better than none at all.

Sara Golemon

unread,
Dec 5, 2016, 11:55:02 AM12/5/16
to PHP Framework Interoperability Group
I was initially on the "keep it on the same line" side, largely as that's how I've been writing it since before 7.0 was released, but the arguments on this thread have convinced me that as recommended styles go, separate lines is better.
 
The one very minor item I would suggest to add to that recommendation is that when multiple declare directives are present, they should prefer alphabetical ordering.  e.g. 'encoding' comes before 'strict_types', which in turn comes before 'ticks'.  Similarly with include/use directives.  This may be outside the scope of this discussion though so feel free to ignore me. :)

Michael Sheakoski

unread,
Dec 5, 2016, 12:00:10 PM12/5/16
to PHP Framework Interoperability Group
Sara, I also favor alphabetical order, but when I was making my example, PhpStorm complained when strict_types came after encoding. Upon further research, it looks like PHP doesn't care about the order of declare() statements, only that they come before other non-declare() statements.

Jordi Boggiano

unread,
Dec 5, 2016, 1:03:56 PM12/5/16
to php...@googlegroups.com
On 05/12/2016 17:55, Sara Golemon wrote:
> I was initially on the "keep it on the same line" side, largely as
> that's how I've been writing it since before 7.0 was released, but the
> arguments on this thread have convinced me that as recommended styles
> go, separate lines is better.

I am still not really sold as I have never seen declare(encoding) being
used and ticks' only use (AFAIK, and especially as far as I've seen in
the wild) was signals handling and that is not needed anymore in 7.1+.

<?php declare(strict_types=1) is short and can't be missed. Long live
the one liner!

Cheers

Larry Garfield

unread,
Dec 5, 2016, 1:30:05 PM12/5/16
to php...@googlegroups.com
I'd say the opposite: My brain is already trained to ignore the <?php
line as noise, so anything added to that line WOULD be missed.

We also need to bear in mind implementation needs. It's going to be
much easier for the spec definition to define "these things, with one
line between them" than "these things, with one line between them,
except in this case where it's inlined, or this case where there's no
blank line, or this case..." And it's going to be much, much easier for
linters and auto-formatters to handle, too, I'd imagine.

I don't have a strong feeling about whether the file docblock or the
declares should come first. But I do favor the status quo of "one line
between each set of things" as it's less complex to define, read, and
parse than the alternatives.

--Larry Garfield

Woody Gilk

unread,
Dec 5, 2016, 2:54:52 PM12/5/16
to PHP Framework Interoperability Group

On Mon, Dec 5, 2016 at 12:30 PM, Larry Garfield <la...@garfieldtech.com> wrote:
I'd say the opposite: My brain is already trained to ignore the <?php line as noise, so anything added to that line WOULD be missed.

Exactly this.

Jordi Boggiano

unread,
Dec 6, 2016, 4:20:52 AM12/6/16
to php...@googlegroups.com
Well for having worked on a few projects with strict types everywhere, I am not sure. Yes in those projects I tend to ignore it, but that's mostly because I know it's there anyway. The bottom line is it doesn't matter a whole lot visually speaking I suppose. If you open a file and don't know if it has strict types or not, the two following things are probably equally obvious.

Inline images 1

vs 

Inline images 2

Same same, except we lose two lines for (I'd argue) nothing.. And IMO it belongs with <?php as it really should be <?php-strict or something, given how it changes the language.

Anyway I guess it's too late and I won't change the outcome of this, but for the record I have to say it: the day I open a class file and I can't even see the `class` token, I shall weep.

Cheers
Jordi

--
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/CAGOJM6%2B_i-VXu1jtu_kj8pO2TonyKKdGmddXCA-U8-n-7FG75g%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.



--
Jordi Boggiano
@seldaek - http://nelm.io/jordi

Michael Sheakoski

unread,
Dec 6, 2016, 2:05:54 PM12/6/16
to PHP Framework Interoperability Group
I have enjoyed reading everyone's viewpoints on this subject. In the end, it has reinforced that at least for my personal standard, <?php declare(strict_types=1) is best kept on the same line for the following reasons:

1. It communicates to me right away that we're playing by new PHP rules in this file.

2. In all of my own projects, and in their composer dependencies, I have not once seen ticks or encoding declared with the exception of some tests in nikic/php-parser.

3. In Jordi's example of real code, the same-line version looks easier for me to parse as a reader, gives an extra 2 lines, and allows the DocBlock to stand out better.

I'm not a member, so there's not much else that I can do or say beyond my initial suggestion. From the responses in this thread, it sounds like there's a 50/50 split in opinions despite the unanimous results of the survey that Korvin mentioned. I hope you guys get it all figured out!

Cheers,
Michael

Rudolph Gottesheim

unread,
Dec 6, 2016, 5:21:33 PM12/6/16
to PHP Framework Interoperability Group
I agree 100%.

In my opinion, the one-liner is far more obvious since we're so used to the short <?php.

I do get the argument of "what about other declares", but really... who uses those? And when the day comes that we get another widely-used declare(), we can still revisit the topic. For the moment, a simple "the strict_types declaration goes in the first line, we don't specify what to do with the others" (okay, I know I'm simplifying a bit) will do the trick.

Am Dienstag, 6. Dezember 2016 10:20:52 UTC+1 schrieb Jordi Boggiano:
Well for having worked on a few projects with strict types everywhere, I am not sure. Yes in those projects I tend to ignore it, but that's mostly because I know it's there anyway. The bottom line is it doesn't matter a whole lot visually speaking I suppose. If you open a file and don't know if it has strict types or not, the two following things are probably equally obvious.

Inline images 1

vs 

Inline images 2

Same same, except we lose two lines for (I'd argue) nothing.. And IMO it belongs with <?php as it really should be <?php-strict or something, given how it changes the language.

Anyway I guess it's too late and I won't change the outcome of this, but for the record I have to say it: the day I open a class file and I can't even see the `class` token, I shall weep.

Cheers
Jordi
On 5 December 2016 at 20:54, Woody Gilk <woody...@gmail.com> wrote:

On Mon, Dec 5, 2016 at 12:30 PM, Larry Garfield <la...@garfieldtech.com> wrote:
I'd say the opposite: My brain is already trained to ignore the <?php line as noise, so anything added to that line WOULD be missed.

Exactly this.

--
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+u...@googlegroups.com.

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

Stefano Torresi

unread,
Dec 7, 2016, 6:08:19 AM12/7/16
to php...@googlegroups.com
Il giorno mar 6 dic 2016 alle ore 23:21 Rudolph Gottesheim <rgotte...@gmail.com> ha scritto:
[...] And when the day comes that we get another widely-used declare(), we can still revisit the topic. For the moment, a simple "the strict_types declaration goes in the first line, we don't specify what to do with the others"

I beg to disagree, and I strongly object to this line of thought; PSRs are meant to last as much as possible, deliberately saying "meh, we'll fix this later" is not exactly promising.
Regarding Coding Styles in particular, we've been shortsighted already: PSR-2 has been due to revision for a long time, for ambiguities and inconsistencies that popped up not long after its acceptance, and redacting a new standards is taking a long time, as everybody can see.

As Larry stated above, we can already abstract a generic rule regarding all "declare" statements, keeping things simple and tidy. Introducing a special case and possible future inconsistencies just for the sake of personal taste is far from ideal, and hardly worth the hassle of revisiting things later down the line.

May I also reiterate on the fact that CS recommendations are not about what people likes, but rather about consistency and cohesion.
If I were to implement a linter and had a rule that enforces to split the same kind of statement among different places, I'd have "WTF" written all over my face.

Regards.

GeeH

unread,
Dec 8, 2016, 10:11:36 AM12/8/16
to PHP Framework Interoperability Group
In PhpStorm land we have our intentions creating it on the first line after <?php with no blank line, which seems to have gone down well with no requests (yet) to change it. If there is interest, I can try to find out how many people are using the intention to give an indication of how widespread the usage is?

Personally, I prefer this too, but in all honesty, I would rather there be consistency (whatever it is) so would take anything here.

G

Michael Cullum

unread,
Dec 8, 2016, 10:21:53 AM12/8/16
to PHP FIG
This would be really useful data if you're willing/able to provide it. It would provide a useful aid to the survey results will be coming out soon (Korvin and I are just finishing up a report on it) but the results weren't in favour of it being on the same line.

M

--
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.

Larry Garfield

unread,
Dec 8, 2016, 10:29:16 AM12/8/16
to php...@googlegroups.com
For the record, I modified the PHPStorm/IDEA template to include a blank line between <?php and declare(). :-)

--Larry Garfield
To unsubscribe from this group and stop receiving emails from it, send an email to php-fig+u...@googlegroups.com.

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

Alexander Makarov

unread,
Dec 10, 2016, 3:52:57 PM12/10/16
to PHP Framework Interoperability Group
Such data would be more than handy. If you have more data about code styles used that would be awesome to get as well.

GeeH

unread,
Dec 15, 2016, 12:49:55 PM12/15/16
to PHP Framework Interoperability Group
I'm currently awaiting confirmation that we can share that data with a 3rd party but it looks like we wouldn't be able to, sadly.
Reply all
Reply to author
Forward
0 new messages