I've spent several days working on my first module and have found the code standards review to be incredibly difficult.
First of all - let me say that I completely agree with strict code standards - and it's vital that new modules stick to these standards in all ways.
My module was written for D6.
As you guys may all be fully signed up module maintainers it might be an idea for me to outline the steps I've worked through recently so you get an idea of the problems for people publishing new modules.
Obviously installed coder and coder_tough_love.
OK - coder_tough_love is reporting 'Line 23: @param and @return syntax does not indicate the data type.' When in fact the data type has been defined. Bit of a nuisance if you know what it means - but a real pain when you don't. According to http://drupal.org/node/1354#functions the data types should be defined in the comment block.
But if I remove the data types (string, int, bool etc) coder tough love and coder report no errors.
Next, install pareview_sh.
This is really difficult to run - needs to be run from the command line - and this takes some setting up. But eventually, it can be run and reports it's result in raw HTML. Again - no biggy - but not easy for new guys. It also means you need to have shell access to the server.
BTW - I could not get it to work over http:// - had to get it to work on local files.
Also - it doesn't seem to want to use coder - but that's OK - we can run coder from the admin interface.
pareview_sh is complaining that the files aren't ending with a newline - when they are - but I add extra lines to all the files - which seems to make it happy
And next - php code sniffer.
Follow the instructions on the page to set it up - not easy - but do-able. Also, I'm not allowed to install PEAR modules on the server - so i'm having to mount the SSH share onto my local file sytem to enable my local phpcs to test the module.
I'm on D6 - so can't just install the module - so I get phpcs from PEAR and install it on the command line. But this version doesn't seem to be as strict as the php code sniffer Drupal module.
phpcs now complains about the newlines ending contradicting pareview_sh.
So I have three different tools - some of which are a real pain to get running - which conflict with each other. This is going to be a real barrier to people submitting modules.
What we need to do it - code, code, code - then run one tool to test the code against coding standards - tidy up - code, code, code etc
Now that http://ventral.org/pareview includes code sniffer it looks like all three tools are running from a single place. Obviously we need to upload the code the the repository before running a test - but no biggie - git is easy enough to use.
Can it be put on the docs that http://ventral.org/pareview is now the single test which needs to be passed? For example - my project is http://drupal.org/sandbox/bailey86/1278830 - and I'd really like to know that because it passes http://ventral.org/pareview the code is fine RE coding standards.
I think I can ask my current employer to supply some server space and bandwith if this would help.