Coder modules has a script in /scripts/coder_format/coder_format.php which lets you run a file or directory through Code Review.

It would be nice to have a "Coder" and "CoderUndo" command as part of this plugin. Maybe take the output from coder_format.php and display it as a diff against the original file?

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

benjifisher’s picture

This will run PHP in lint mode (syntax checking) on the current buffer:

:set makeprg=php\ -l\ %
:make

See :help quickfix for details.

We can write a compiler plugin to set 'makeprg' and 'errorformat' appropriately for code review. Maybe use "drush code-review". Then all you will have to do is

:compiler coder
:make

If you want to use Coder to generate a replacement file (or update a module to D7) then we could write a few plugins.

Do you know about vim's diff mode? It rocks.

$ gvim -d foo.php bar.php

or

$ vim foo.php
:diffsplit bar.php

See :help diff-mode for a full explanation or :help 08.7 in the users' manual.

benjifisher’s picture

See also the Drupal Code Sniffer, http://drupal.org/project/drupalcs . This is being used in automated reviews of project applications.

benjifisher’s picture

Assigned: Unassigned » benjifisher
Status: Active » Needs work
FileSize
988 bytes

The attached patch is a first step. There is still work to be done.

For starters, try

:compiler php
:make %

This will invoke the PHP compiler plugin included in the standard vim distro, then run it on the current file. Pretty much like what I suggested in #1 above, invoking PHP in lint mode.

See :help 30.1 for an introduction to using vim's quickfix mode in the users' manual, :help quickfix.txt for complete details.

Now, after applying the attached patch, try this. Edit a file, like mymodule.module, that is inside your Drupal directory, and make sure that the Coder module is installed inside the same Drupal installation. Then

:compiler coder
:make %
:e!
:diffsplit %.coder.orig

should run coder_format.php, as suggested in the issue summary. Note that this is aggressive: it replaces mymodule.module with the processed version, saving the original in mymodule.module.coder.orig. Vim should warn you that the file you are editing has changed, and give you the option of loading the new version into the editing buffer. (The :e! line in the above snippet does this manually.)

See :help 08.7 in the users' manual and/or :help diff.txt for details on vim's diff mode. As I said in #1, it rocks.

Untested, but these should also work:

:compiler coder
:make another_file.php
:make includes/myfile.inc
:make includes/
:make .
:make %:p:h

The last two run coder_format.php on the current directory and on the directory of the current file, respectively. The script coder_format.php knows what to do when given a directory rather than a file.

If you like this approach, here are some ideas for improving it.

  1. Be more efficient when looking for coder_format.php. Currently, the compiler script searches everywhere in the Drupal installation for it. If it is not there, this can take a while.
  2. Be more graceful when coder_format.php cannot be found, or if the php CLI command is not found.
  3. Provide fall-backs for Drupal installations. For example, I have Coder installed in my D7 sites/all/modules/ but not under D6.
  4. Maybe enter diff mode automatically. Would a pop-up window explaining what is going on be more useful or annoying? I think the QuickFixCmdPre and QuickFixCmdPost autocommands are our friends.
  5. Documentation!
kostajh’s picture

Along the lines of point #3 above, would it be possible to manually specify the path to Coder (or coder_format.php)?

For example, perhaps in drushrc.php (~/.drush/drushrc.php) we could have an option $options['coder-path'] = "~/.drush/coder/coder_format.php". Or there could be an option to use wget/curl to download coder_format.php and place it in the users .drush directory?

benjifisher’s picture

@kostajh, tell me more!

I did suggest using drush in #1 above, but I have not tried it yet. That would be one way to use drushrc.php for customization: use drush in the 'makeprg' setting, instead of calling php directly.

Did you have something else in mind? Perhaps one of our vim scripts could parse drushrc.php for some information. Probably is is better to let drush do the work.

benjifisher’s picture

P.S. Maybe you can help me avoid some RTFM. I am still a drush newbie, using only "drush dl", "drush en", and "drush up". Until today, I did not have a drushrc.php. I tried creating ~/.drush/drushrc.php with the following line (after an opening php tag):

$options['coder-path'] = "/path/to/drupal/sites/all/modules/coder/scripts/coder_format/coder_format.php";

but I think I need to do something more to tell drush where to find the coder-review command. Probably something similar. (If I am editing a module inside my D7 installation, where Coder is installed, it works fine. I am trying to figure out how to get it to work inside my D6 installation.)

In short, I have not yet figured out where to look for drush documentation. :-(

kostajh’s picture

@benjifisher - you can go to ~/.drush and type `drush dl coder` which will install coder for you 'globally', but the problem is that Coder requires a Drupal bootstrap to run, so `drush coder-review ~/path/to/example.module` won't work unless `~/path/to/example.module` is within a Drupal directory.

This is why I think using DrupalCS might be a better option for this project.

The best place for Drush documentation is in the examples sub-directory in drush. You can also check out drush.ws.

kostajh’s picture

By the way, just came across this helpful guide to DrupalCS/Vim: http://echodittolabs.org/drupal-coding-standards-vim-code-sniffer-syntas...

benjifisher’s picture

@kostajh:

Thanks. Now I understand why you used the path ~/.drush/coder/ in #4 above.

I installed Coder "globally" as you suggested (#7), and I am making progress:

$ drush help coder-review
usage: drush coder-review [options] [severity] [review] [what]
  options:
...

I am inside a Drupal directory:

$ drush status
 Drupal version         :  6.22
...

(Don't worry, this is just my development server, not a live site!) As I said, Coder is already installed in my D7 directory, but not here. Still no success:

$ drush coder-review mymodule
Command coder-review needs the following modules installed/enabled to[error]
run: coder_review.
The drush command 'coder-review mymodule' could not be executed.   [error]

(Module name edited to maintain a suitable level of paranoia.)

It seems odd that the coder_review module has to be enabled for this to work, but that seems to be the way it works. I had to run drush en coder_review in my D7 directory to get it to work.

I already suggested drupalcs in #2 above. I agree, it has a lot of advantages, especially if we can get it installed automatically with our installer, #1145580: Add installer?. There must be something very funky about the way PEAR got installed on my Mac, because I had a lot of trouble installing PHP_CodeSniffer.

Thanks for the tips on drush. The example drushrc.php looks useful, and the sample scripts will help when I am ready to try scripting. I still need something more basic. Last time I checked, drush.ws was overwhelming.

The blog post you mention reminds me that I should have a look at the syntastic plugin. Also git submodules. Although it looks as though Syntastic added support for phpcs in version 2.1.0, about a week ago, so maybe it is just as well that I waited.

benjifisher’s picture

Version: » 7.x-1.x-dev
Status: Needs work » Needs review
FileSize
1.72 KB

Here is a new version of the patch. Once we commit it, I will add further options for compiler settings and Syntastic support.

First, please test as in comment #3. I think that options relying on the Coder module, or anything that involves bootstrapping Drupal (such as drush code-reviewor Coder upgrade) should follow this model, using :make or :lmake or some variant.

Next, install Syntastic, phpcs (executable), and Drupalcs. Follow the instructions for symlinking the DrupalCodingStandard directory to the CodeSniffer/Standards directory. Then phpcs should run automatically each time you read or write a buffer. If necessary, introduce some violations of coding standards, like two spaces after an operator, and try

:SyntasticCheck
:Errors

Since phpcs is fast, it is appropriate to use with Syntastic. We can also provide a compiler plugin so that it can be used without Syntastic.

Of course, if you can test only one or the other, please do. Maybe someone else will do the other test!

ethanw’s picture

I've opened a separate issue, #1460614: Add support for DrupalCS Syntastic Code Checks, for the Syntastic integration. I think there is now a better solution for that piece than I posted in the original blog article.

Original version of this comment below, for archive's sake. Removed due to the topic of this ticket being Coder support, not Syntastic/DrupalCS.

Syntastic now supports multiple filetype checking, so we can add a drupal syntax checker directly w/o needing to modify any global variable settings. The attached patch adds a filetype-based syntax checker for all files with ft=drupal (this may need to be adapted for css.drupal files!), without requiring any additional vimrc configuration. It should work out of the box on any machine with syntastic and drupalcs installed. I think this method is superior to the one in the referenced blog post...I'm going to post and update to the post with this recommendation.

Note that this does not include compiler support. I don't personally use compiler and don't think syntax checking should depend on it's being installed, but I might be misunderstanding. Perhaps that can be bundled as a separate patch?

benjifisher’s picture

Title: Add support for Coder code reviews » Add support for Coder code reviews and Syntastic plugin
Status: Needs review » Fixed
FileSize
2.73 KB

I have committed (134180a) the attached patch, which includes the one from #10 and adds documentation. See :help drupal-coder. (Remember to run :helptags or :Helptags after applying the patch.)

Like the patch from #10, this adds suport for the Syntastic plugin. I have not added any documentation to the vim help file, but I will add some to the documentation pages for this project. I also updated the title of this issue to reflect the Syntastic support.

benjifisher’s picture

I forgot to commit the documentation and the Syntastic support. New commit: 5be8c6b.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.