Re: Questions of code standards

On Jul 17, 2008, at 6:35 PM, Kristopher Ives wrote:

I code in a different way than PEAR's coding style standards, mainly I use tabs and don't like spaces between my opening brackets.

I too used to code a different way. Then I realized that I was committing a bunch of code to PEAR and got lazy so I just followed the herd. I figure the PEAR coding standards are more heavily vetted by people smarter than me. Also, as I said before, I'm lazy. We follow these same standards at Digg with a few slight modifications for template code.

1.) Anyone currently code using tabs and have an Eclipse or bash script (using some whitepsace program) that formats to PEAR standards?

You can open files in vim and type "retab" to change tabs to spaces I

think. Otherwise, off the hip, sed s/\t/    /g could very well do it.

2.) My PEAR package has 80+ source files, is this a problem? I am not interested in combining source files into larger ones.

PEAR doesn't have any limit on the number of files a package may contain that I'm aware of. The general rule of thumb is one file per class, though I've seen this broken in a few places. The one thing you may want to consider is breaking your UPS and DHL drivers into sub-packages that can be optionally installed (See MDB2 and Validate for examples of subpackages).

3.) Should I include my 2 driver packages (UPS and DHL) in my original proposal for Services_Shipping (these would be Services_Shipping_UPS and Services_Shipping_DHL, correct?)

Yes. Propose the whole thing and we'll worry about breaking things up into sub-packages once the whole thing has been approved. Unless someone chimes in and says that's wrong, which is entirely possibly since I'm often wrong. :)

4.) Should I generate documentation (phpDocumentor) and include the documentation or only submit my code and PEAR will generate the doc?

Documentation isn't created for proposals. Once your package is created and released PEAR handles the creation of the phpDocumentor documentation. The management of DocBook documentation is handled outside of your package (though you're free to include the DocBook sources inside of your package - see role="doc").

5.) After proposal will I get a reason why my package isn't accepted so I may fix the issues and re-submit? Is there a limit on how quick I may re-submit my proposal?

It's very rare for a package to be patently voted down. There are three phases to the proposal process: draft, proposal, voting. Normally all of the issues regarding style, performance, viability, etc. are addressed during the draft and proposal stages, which have no time constraints. What I normally do is leave my packages in a proposal state until I've been able to address all of the concerns raised by the community (whether that's fixing the code or simply rebutting their concerns). Hope that all helps. Let us know if you have further questions. Also, thanks! --Joe