Rules for PHP 7 features about coding-standard HOT 11 CLOSED

@mhujer "Typehints for primitive values should be always used" and more should be solved in https://github.com/slevomat/coding-standard/blob/2.0-dev/SlevomatCodingStandard/Sniffs/TypeHints/TypeHintDeclarationSniff.php

from coding-standard.

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.

from coding-standard.

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

It is not merged yet though.

from coding-standard.

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.

from coding-standard.

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.

from coding-standard.

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

from coding-standard.

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

from coding-standard.

I see :)

from coding-standard.

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

from coding-standard.

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.

from coding-standard.

Resolved with 1.0 release https://github.com/consistence/coding-standard/releases/tag/1.0

from coding-standard.