Hopefully, my last blog post convinced you to avoid long lines. The php community has a nice coding style guide called PSR-2 that says the followin...
For further actions, you may consider blocking this person and/or reporting abuse
I voted a unicorn because it's you. :-)
Your old one line signatures' enemy will try to answer you. <3
Be prepared, you will be surprised for some parts. ;-)
This is true. This is not about a debate here, it's a fact.
Well, this is a little bit more complicated than that in my opinion. I'll try to explain clearly.
You are quite right, since php 7, most of the phpdoc type-hinting became duplicate and useless. But some only.
For basic type, they are, for sure. But for object, it could be more complicated. Sometime you have to specify some sub-classes on the phpdoc to get IDE completion working.
So you will tell me that we can only specify those special parameter. Well, it could be but two points:
So now you will maybe tell me that in this case, we should put the phpdoc only when some parameters needs to be specified and nothing for the other.
It's an idea indeed, but here too I see two points:
I'll conclude this part because the PHPDoc can be a good discussion for another article: At this time, I think both are great.
Well, I think you will lie if you deny to talk about Sonata Project as an example. :-)
I don't totally agree with your argument. For the case of Sonata, we don't have a lot of time maintaining the repositories and I really think following a big standard is give more benefices than define our own.
And, as 99% of our projects are Symfony bundles, it makes sense to follow SF standard.
We have indeed some necessary exceptions, like short array for example. Yeah, no need to tell me, I opened a trolling hole here. :-D
Beside the comment I did, it's a great article. Really. And I agree especially for that point: PHP 7 type hinting give us more flexibility and force us to get new reflection and debate about multi-line signature and the usage of PHPDoc.
Also one concern for my case: Beside the rule you choose (multi or single line), I think this should apply every where, like the
,for the multi-lined arrays. You know, for git conflicts? :-)Best regards.
Great answer thanks!
Let me address a few of your points:
Indeed, I will
The typing is far, far more reliable than the comments. IDEs should strive to use the former if they do not already. Comments rot, and are often wrong, as phpstan shows.
And I think they can take it. Not a big deal if they themselves feel that the comments are a bit redundant, which they very often are.
Not only! Api-platform gives the same reason when asked, but yeah, Sonata is of course the example I had in mind, but I didn't want to point fingers (except for Magento :P)
A bot can hardly determine if a parameter needs a comment, since now the typing is described, all there is to describe is non-obvious behaviors, which you cannot know about unless you understand the code.
We have linters to cherry-pick the rules we want. We could do that once and for all, and that wouldn't be a big deal. The Symfony standard minus the rules we don't like could be great.
I don't think we should go that far, even if that kind of stuff can indeed be the source of some conflicts.
I'm not talking about IDE relying, but comment generation. ;-)
I think that feature is now useless and should be removed. It just empowers devs to generate what often ends up being useless noise.
Maybe it can be improved, but not removed.
Otherwise, I'll just use ed. :-P
I think it should be completely okay to "clutter" an interface with signatures, because you are definitely not supposed to have many methods in an interface, see the ISP. Plus, even if you don't change them often, they should still be easy to read too, especially in the Github editor.