chore: PHPDoc key-value spacing #7592
Conversation
| * @param string $input | ||
| * @param \Closure $fn | ||
| * @param \Closure(bool):int $fn2 | ||
| * @param Closure $fn3 | ||
| * @param Closure(string):string $fn4 | ||
| * @param array<string, array<string, mixed>> $data |
There was a problem hiding this comment.
Can we get rid of phpDoc horizontal alignment in the project? I find it totally unneeded. Not something that bothers me, though.
There was a problem hiding this comment.
Please don't, the phpdoc would then we very less readable.
There was a problem hiding this comment.
You must be a superhero, everyone else in the world needs and use the horizontal alignment :)
There was a problem hiding this comment.
To be honest I have never worked in a place where horizontal alignment was used. None of my teams had it configured (10+ years). Right now I work with GetResponse and there are dozens of developers in the 2-million SLOC app, and we don't use alignment. Not a single developer ever complained about it 🤷♂️. For me it's a waste of space and personally I find it less readable, especially when there's a huge gap between type and variable forced by some other, longer type. Displaying white chars somehow helps (you can match better), but still a noise.
There was a problem hiding this comment.
@Wirone , please be mindful that you complain about whitespaces in test of fixer doing those whitespaces :D it's a crazy example here, but that's the purpose of the test.
I aim to not have as such crazy docs in actual code - regardless if with or without whitespaces - by having docs only for those params that are not typehinted on method prototyped or requires extra typing (eg array vs list) or detailed description. We do not have so many of them.
After saying that, I prefer to have those horizontal alignments for docs, and it's coming as a habit from a quite popular ecosystem - Symfony.
I acknowledge that different ppl have different preferences, thus I want to go with PSR/PER + Symfony and potentially build on top (eg strict rules), but not against rules from base rulesets. This simplify a lot the discussion "which rule to use"
There was a problem hiding this comment.
First of all I am not complaining, I just asked if we need this particular rule/option enabled in our internal ruleset, because I personally don't like how phpDocs look like in the codebase (even if there are not lot of it) 😉. I don't agree with reasoning that @PhpCsFixer should only add to parent rule sets, for me it's only a way to achieve custom ruleset, and if it's easier to extend from other ruleset and then remove/change 1 rule, rather than defining N rules without using base ruleset, then it's totally fine. I don't need simplified discussion, I prefer things I like 😅. But in the end it's your choice.
There was a problem hiding this comment.
exactly, everyone will have different preferences, we have soooo many rules ;) thus this simplification on own ruleset decision making I done for project.
No description provided.