Juliette

> > Can this be added in this fork of code sniffer, or should we be patient and wait for the official release from the squizilabs guys? > We have...

@dingo-d That would be a great starting point. Ryan has opened a PR for the [ESLint sniff upstream](https://github.com/squizlabs/PHP_CodeSniffer/pull/1374) in PHCPS, just waiting for it to get merged. Once it is,...

@dingo-d If I look at this config, it appears opinionated about code style which is something which the theme review checks should **not** be. However, it could be acceptable for...

The ESlint sniff has been merged upstream and will be in the next PHPCS release (2.8.2/2.9.0).

@dingo-d Looks much better! All the same, it still feels opinionated. You include quite a few best practices, which - while I totally agree that theme devs *should* comply with...

> I've left some rules in, which I thought would be a best practice, but they should throw a warning. `no-useless-concat`, `no-else-return` just to name a few ? I just...

@justintadlock Just wondering: What bugs you about that ? There is nothing essentially *wrong* with code like that. This is the ESLint rule detail - just to make sure we're...

@justintadlock Ok, thanks for the clarification. IMHO a sniff like that *could* possible be added to the WPCS `Extra` ruleset which is more focused on best practices, but has no...

Checking for (parse) errors and faulty code is definitely ok. Checking for unused code can probably be grouped with that as unused code shouldn't be shipped with a theme. Anything...

Oh and what I forgot to mention: ### Discussed WPCS 1.0.0 * Talked through and merged PR #165 to update the TRTCS with the changes in WPCS. * Talked through...