Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Parser: Tabs or spaces? This never should have gotten in #10379
This file could probably be added into the phpcs config so it'll be caught next time!
@chrisvanpatten these lint rules are pretty mismatched with this module. I'm struggling to decide…
any thoughts? if not, how about we remove this from the
@dmsnell Aside from the tedium of making the changes is there any technical reason this class should be exempted from the WPCS rules? It's flagging a lot of things but none of them strike me as unreasonable.
I can appreciate wanting to keep the JS values consistent with PHP (with things like innerHTML) but otherwise it seems like the rest could be fixed.
Happy to take over and fix as much as I can, if you'd like…
@chrisvanpatten definitely not asking for this to be exempted, though I am questioning how to apply the rules best and if they ought to be exempted.
the tedium of making the changes is completely absent from my thought process. I can make the changes faster than I can tie my shoes
it's more like in this case, I'm trying to do a cleanup on this file and get it moving forward and ready to make more cleanups, but after adding it to
what's unreasonable is that the fixes I'm making to appease the linter aren't making the code any better.
this is unsatisfactory:
this is satisfactory:
this is wrong:
this is right:
once I started adding the comments to ignore the rules that don't apply it started making the code harder to understand for me and annoying to copy and paste, plus it irks me that we're so tightly mixing the code which implements a parser specification and code hidden in comments which interacts with linting (thus the question about a separate set of XML rules for
mainly I think I'd like to agree with @mcsf if you are willing to remove the
Definitely don't consider my opinions as blocking!
Sure, and we could bikeshed on this all day, but at the end of the day they are the WordPress coding standards, this is a WordPress project, and these are the standards that the WordPress project has decided to adopt. They are definitely aggressively prescriptive (I personally use PSR-2 on my personal projects because I don't really like WPCS) but they are the standards we have and as a core project it seems like this is a case where they should be used.
But I personally have no problem at all with tackling that in a separate PR; I'm even happy to do it myself after this is merged :)
Thanks! I'll merge as soon as the tests to finish green then - some unexpected issue came up and I don't know why (the diff is now empty when ignoring whitespace)
the point is that we don't just need a
it's not bike shedding unless we're arguing about meeting the letter of the law while ignoring the reason the law exists in the first place
would be awesome. I also don't mind. also, if you do, would you mind pinging me on the PRs as well? if there are any questions I'd be happy to share insight behind the code. also, I'm still not convinced that adding a bunch of inline
Oct 10, 2018
What was the original pull request which introduced the issue? Curious to find more context on why we want to allow this exception:
the parser specification defines the variable names and they were chosen to be the same in JS as in PHP to enforce consistency. the idea is that nobody building a new implementation should have to ask how to change variable names based on language idioms - the contract is a JSON-ish array of block objects
in other words, if you parse a document in the server it should produce identical output as parsing it in the browser would