Php-cs-fixer: Fixer added dot at the end of line with a :

[OskarStark]

For configuration or updating questions please read the README and UPGRADE documentation,
or visit: https://gitter.im/FriendsOfPHP/PHP-CS-Fixer

When reporting an issue (bug) please provide the following information:

The PHP version you are using:
$ php -v - 7.0.14

PHP CS Fixer version you are using:
$ php-cs-fixer -V - 1.11.2

After a run, I got this diff:

- * API field for dividing livestream types in a boolean way:
+ * API field for dividing livestream types in a boolean way:.

Imo this :. should be avoided, what do you think?

[keradus]

Your docblock is invalid. You have In your docblock a description section, while valid docblock requires summary section before description if later exists

[GrahamCampbell]

Maybe we should actually change our fixer to either delete the colon and replace it with a full stop, or to skip such cases, since the phpdoc is already invalid?

Perhaps could be suitable for configuration, since, this fixer is useful for people to catch and fix their already invalid phpdoc, like in this case?

[keradus]

why not. feel free to send PR ;)

[SpacePossum]

Why don't we skip PHPDoc's that PSR5 states are invalid, same like we skip invalid PHP code?

[lbassin]

I am working on a PR to ignore doc blocks if they don't match PSR-5 but i was wondering:
Can we consider that a summary longer than 2 lines is always invalid ? PSR-5 only RECOMMENDS us to keep summary smaller than 2 lines

Also, I need your opinion on another case:

    /**
     * I don't know if this block is a summary:
     */

What should we do with this one ? IMO we should remove the colon

[SpacePossum]

Can we consider that a summary longer than 2 lines is always invalid ? PSR-5 only RECOMMENDS us to keep summary smaller than 2 lines

for this rule, I would vote yes :)

What should we do with this one ? IMO we should remove the colon

if the summary is valid, as the sample is, but doesn't end with a sentence (full stop/period, exclamation mark, question mark), than it should add the dot. So in this case it leaves the removal of the : to the end user if wanted by the user.
It is an edge where we should throw a ton logic against IMHO as parsing languages is hard enough to get right (for example the rule only works for languages written from left to right to begin with...).

[GrahamCampbell]

I'd vote for not changing the behaviour, since it informs the user their doc is bad.

[SpacePossum]

The tool should either fix the code or not, it is not a sniffer that informs users. Therefore it should not touch docs that are bad and cannot be fixed to be good. Just like it does with bad PHP code it cannot fix, it should ignore it.

[GrahamCampbell]

I'd rather it deleted the colon and added a period, then.

[GrahamCampbell]

Than do nothing.