Fix codestyle. #590
Fix codestyle. #590
Conversation
…re standard. (Not the tests themselves as those are supposed to contain code which will fail.)
As that was the only error left for the WP-Extra ruleset, might as well activate it too.
| 'wp_kses' => true, | ||
| 'wp_kses_data' => true, | ||
| 'wp_kses_post' => true, | ||
| 'wp_kses' => true, |
There was a problem hiding this comment.
Honestly, I'm not big on these array alignment. It can make things look better, but IMO it isn't necessary when all of the values are currently the same, and it will inevitably get out of sync next time a longer function is added to the list. When that happens we're either going to realign the whole array, or we'll end up with a partly aligned array, which after a while will put us back in square one. :-) I'm not going to complain if others disagree, but I just thought I'd mention it in case anybody wants to give a second opinion.
For the record, the variable alignments look good, I'm just talking about these array alignments.
Or do we still sniff for array alignments? I don't think that we do. Or else maybe I've disabled that (but I don't think so)...
There was a problem hiding this comment.
Or do we still sniff for array alignments?
No, we don't.
There was a problem hiding this comment.
I'd prefer alignment for the multiple times code like this will be read by developers, over the relative few instances that someone might need to adjust the spacing because of an addition that has more characters. FWIW, in PHPStorm you can highlight, hit a keystroke (mine is CMD+Shift+L), and they will all align anyway - no need for manual alignment.
There was a problem hiding this comment.
I think it would complicate things if we say we don't do variable alignments if the value is the same otherwise we we do it.
There was a problem hiding this comment.
OK, we can keep them aligned. My issue isn't that it will be trouble to realign them (I use PHPStorm as well), but that doing so makes history harder to follow. But I guess it does make sense to prioritize the most common use, which is devs looking at the lists just as they are.
As this clashes with `WordPress.WhiteSpace.ControlStructureSpacing.BlankLineAfterEnd` for the last method in a class, I've - for now - resorted to adding `// end` comments after the method closing brace to bypass that error.
* Fix some missed "class opening brackets on different line" issues. There currently is no sniff checking for this, so visual fix. * Fixed one class extending the wrong parent.
* Added generic file docblock to sniff files which didn't have one. * Added/replaced generic file docblock for all unit test files. * Use `@link` rather than `@see` for links to external documentation about a sniff in the file/class docblock. * Consistent placement of the `@link` tag if available and pointing to WPCS relevant info. * Removed `PHP version 5` notes. No longer relevant. * Fixed a few class description referring to the wrong rule/sniff. Docs still need a lot of love to get up to scratch properly.
|
Added two more commits: Minor touch-up.
Documentation fixes.
Docs still need a lot of love to get up to scratch properly. This is just a small step in the right direction. |
|
As far as I am concerned, this is ready for merge. Any other comments or objections? |
|
|
Complies with WP-Core.
As there are only two warnings left when run against WP-Extra, I've activated that as well. Might as well lead by example ;-)
Still would need some work to comply with WP-Docs. When run against Docs PHPCS currently yields some 100 or so issues mostly to do with file vs class docblocks.
Also:
Closes #256