Giters

consistence / coding-standard

Consistence - Coding Standard - PHP Code Sniffer rules

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Rules for PHP 7 features

mhujer opened this issue · comments

commented

PHP 7 added new language features that can be formatted in different ways. It would be great if Consistence can define its way to format them. e.g.

  • declare(strict_types = 1) - just after the PHP or on a new line?
  • Return type hints - FQCN or not?
  • Primitive type hints
commented

I this most of those you can find at Slevomat slevomat/coding-standard#53

It is not merged yet though.

commented

Yep, we have support for a lot of 7.0 features in the 2.0-dev branch. I'm responsible for finishing and polishing 2.0 but I prioritized working on PHPStan over the holidays :)

You can find out what will be in 2.0 here in this Trello board. Unfortunately PHP 7.1 was released meanwhile so I feel the obligation for the Slevomat CS to also correctly work with 7.1 features.

commented

Yea, I am sure planning add these, we are actively using them, I was just waiting if there would be any potential tweaks and wanted to release it as 1.0, so was finding out if there is something else worth adding/changing/removing.

The rules for PHP 7 stuff:

  • declare(strict_types = 1) on a separate line - this is because i think there will be more of these declarations in the future and also it fits more with the overall Consistence standard, where everything is more structured
<?php

declare(strict_types = 1);

// ...
  • return type hints are the same as parameter typehints, so no FQN
  • return type hints are written with colon just after closing parenthesis and a space after the semicolon:
<?php

function foo(): string
{
    return 'hello';
}

@mhujer I am not sure, what do you mean by

Primitive type hints

?

Also the thing I was still thinking about was if PHP 7.1s nullable types should be marked differently in PHPDocs (perhaps using the ? as well) or if it should be just |null as it was until now. I am inclining to the second variant because there can be more types and also it seems cleaner from the typing point of view.

commented

Our Slevomat CS sniff about declaring strict types is configurable, so there can be zero to N lines between PHP opening tag and the declare statement. We personally use 0 lines so it looks like this: <?php declare(strict_types = 1); mainly because this feature was described in the RFC this way and it's the most compact version. Also, if there will be multiple things like this in the future, they will probably fall in a single declare statement, like when you're declaring ticks today.

commented

@VasekPurchart

@mhujer I am not sure, what do you mean by

Primitive type hints

Probably scalar type hints, like string in public function method(string $args).

commented

Yea, but I am not sure if there is anything what should be decided in the scalar parameter type hints :)

commented

I see :)

commented

@ondrejmirtes I'm already using development branch of Slevomat-sniffs because of PHP 7 :-)

@VasekPurchart I meant that the primitive typehints will affect do/don't related to the PHPDoc - https://github.com/consistence/coding-standard/blob/master/consistence-coding-standard.md#methods-without-phpdoc. And also that something like "Typehints for primitive values should be always used" can be added.

commented

I have finally had the time to write this up: #9 PHP 7.0 and 7.1 coding standard rules, in the end I managed to get there also rules for PHP 7.1 (and a few other not mentioned here before).

Please check it if you see some odd things or something that I might have forgotten.