Use external library for coder review

and there is https://github.com/ericduran/drupalcs that is based on PHP_CodeSniffer

I'm not sure I understand this request. Is there a reason we need to switch to an external library? We don't even really need to switch to use the grammer parser api module, it's just a nice to have. There's nothing preventing the existing module framework from integrating with PIFR, etc. Is there something I'm missing here?

Note: responses from me may be slow as baby Ailbhe is barely 5 days old. :)

1) PHP_CodeSniffer comes with existing rules that we can leverage, so we do not have to maintain them on our own (line endings, indentation, white spacing, etc. etc.)

2) PHP_CodeSniffer uses a tokenizer to process the files. So it is much more easy to add a rule like "do not use t() in hook_schema()" with PHP_CodeSniffer than to come up with a fancy regular expression.

I am working on an automated script to review project applications (PAReview.sh) where I use Coder and drupalcs to do some checks. I'm interested in integrating more complex rules (e.g. all comments should start capitalized but only if there is no comment on the previous line or if the comment on the previous line ended with a "."). I don't see how I could do that properly with Coder or Bash at the moment.

So my current battle plan is to fork drupalcs on d.o and to migrate all coder rules (code style is pretty much done out of the box; security, translation, SQL etc. need to be migrated). Maybe I will fork Coder in a sandbox too, because in the meantime I need a tandem-mode of Coder and drupalcs and I don't want duplicate errors in the generated reports. So I would remove rules from Coder when they have landed in drupalcs.

I myself have not much interest in integrating PHP_CodeSniffer into Coder (because the rules run stand-alone from the shell anyway), but I can give support if someone else would want to do it. But first I will have to see how far and how fast I can get with PHP_CodeSniffer anyway.

Ah, as I just saw http://drupal.org/project/eclipse_code_validator is just a set of PHP_CodeSniffer files, so I think I will join that effort.

klausi, das-peter, and I have actually join our projects into one sanbox for now. This way I can stop commiting to github and we can all work together on improving the PHP_CodeSniffer rulesets for Drupal.

The big difference between coder and the code sniffer at least for me, and what got me started with a different tool is that coder requires a drupal site to be installed. In my case this wasn't great because I wanted to validate a single file before a user commit its (in a git pre-commit hook, which is possible with drupal, but so much easier if you can just run the check in a file).

After this, it was also easier for us to set up this tool on any environment whether or not we had drupal install.

It should also be noted there's a seperate feature request about getting coder to run at a lower drush bootstrap level to reduce some of this pain. The issue is over at #1155686: Allow the drush coder-review command to run at a lower bootstrap.

Promoted to a full project at http://drupal.org/project/drupalcs

Two suggestions
1. create a new rule type (see do_coder_review) that uses the new parser, and replace one rule at a time. Note that most people think of the coder regex rules, but we actually also support grep, grep_invert, and custom callbacks. I'm suggesting a new rule type called 'parser' or 'codesniffer' or whatever.
2. make sure that any rule that is replaced has a good test

I think this is done, see also #1774168: Coder Code Sniffer review