Getting a peer review for my new plugin?

1 Views

What is the best way to get an experienced WordPress developer take a look at my plugin and give constructive criticisms? I have written code to solve some of my questions on this site, and I think they could be useful to others too. However, since they would by my first public WordPress plugins, and I have seen many not-so-great examples in the public WordPress directory, I would like to know “where I stand”, and how I can improve my plugins. I have read the list of best practices, and still need to apply some of them, but I would also like an answer to the more general question “Is this a good way to solve this problem?”

I just re-read the related discussion on wp-hackers (I did not realize that the participants were also so involved in this site, and that the “best practices” question is a direct result of it). I’m not sure my needs would be covered by such a system, and I agree with Paul’s concerns:

Read More

When I read the original comments on this thread last week I though the purpose was to put together a peer review process where plugin developer can offer advice to other plugin developers as review of their code. I originally took this advice as something along the lines of “Well, your code works but this set of routines you’ve written would be better served if you just hooked into this WP filter and tried this technique (see xxx plugin as an example)”. The goal I thought was to share WP plugin development knowledge and make any mediocre plugin developer a better developer. Like myself.

This would be a different scope than doing a point-by-point checklist review, it would be more of a “mentorship”. It seems there are many people willing to do this, and (even better) many of them participate here on this site, so how can we transform all of that energy into something concrete?

My current example are three plugins I wrote to solve my “image resize” problem. I wrote long introductory comments to each plugin, which (I hope) makes it easier to understand my intentions without reading the full code. Is there anything else I can do to make it easier for others to take a look at it? Please ignore my current concrete request. Not only is it too early for them, but I changed my mind and don’t want to spoil the general discussion with my specific situation.

Post Views: 1

Related posts

Leave a Reply

3 comments

  1. The easiest way is a two step approach:

    1. Release your plug-in to the public. Once it’s live, you’ll start getting feedback from end users in addition to developers. If you want, release it as a “beta” version and heavily emphasize that in the readme file.
    2. Ask. There are veteran WordPress developers everywhere: here, on the WP-Hackers list, at WordPress jobs, stalking @wordpress on Twitter, etc. It’s just a matter of throwing your plug-in out there and asking for feedback.

    In general, follow the same steps as you would getting a Core patch looked at by a developer:

    • Write it
    • Document it
    • Contact a developer (either broadly through one of the above channels or directly if you can) and ask for feedback

    As far as transforming the kind of “mentorship” that occurs on this site into something more concrete, that would be an organic process. As you’ve already mentioned, efforts to create a kind of plug-in review process before actually reviewing anything seem to have stalled. The only way to get anything off the ground is to actually start doing it. So don’t just talk about finding a veteran developer and getting feedback, go out, find one, get your feedback, and write down how the process went.

    Then it can be repeated with future plug-ins and future developers. But you’ve got to start somewhere …

  2. After a quick look at https://gist.github.com/675437 I saw some minor points, mostly about readability:

    • Write good code documentation: Docblocks … and inline comments whenever something isn’t absolutely clear.
    • Split looong functions into shorter separate functions. They are easier to read and to address in reviewer’s comments.
    • Align your assignment operators, add whitespace between parentheses.
    • 80 characters line length, please! Eclipse still cannot wrap long lines. 🙁
    • Keep your code »left«, save indents. Instead of:

    .  

    public function checkUrl()
{
    if (is_404()) {
        // code
    }
}

    … write …

    public function checkUrl()
{
    if ( ! is_404() ) {
        return;
    }
    // code
}

    I have written a new plugin just tonight … and I was wondering if I may ask exactly your question. Good timing. 🙂

  3. It just made me think of Appscan: http://www01.ibm.com/software/rational/products/appscan/source/ ; http://www-01.ibm.com/software/rational/products/appscan/source/features/ trial of light version: http://www-01.ibm.com/software/awdtools/appscan/express/

    This can do php and one can put extra rules in it to check for things. In that way a part can be automated (like some best practices as in the answer from toscho), it can check for security, coding standards, optimizations etc…

    I’m just saying: if a tool can check for 80% then the 20% checks for the manual checks for a guru would be less. It would also help to generate compliance reports for use of a plugin within a large company that demands these kinds of things around additional code.

    We automate things for other people so why not for ourself?