Re: Questions of code standards

Thanks for the help. Before I continue I want to ensure my messages are properly being sent to the mailing list (specificly in reply). I use GMail and use the Reply To All option which replies to the message I click and CCs to the mailing list, is this legit? I use the PHP DOMXML class/functions (which are included by default), but I think PEAR has some XML classes too. I don't really want to rewrite everything, and the DOMXML and DOMXPath stuff works really well so far. I am making my proposal tonight, do you think this XML class will be an issue? On Thu, Jul 17, 2008 at 9:11 PM, Joe Stump <joe@joestump.net> wrote: > > 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 >