Re: coding standard - not again!

Lets eat the bait :) Coding Standards are great, wonderfull, essential and required - had to say that before i get into the blasfamy below :) This ?short? little email is really to empasise 2 points 1. the need for a 'prePEAR' repostitory 2. the need to modify the naming conventions in PEAR (wow bit more controversial) At present, PEAR is viewed by most casual visitors as a little eliteist (in the politest sense), Alot of people would like to contribute code to a central repostitory, and allow others to use it - and gain the obvious benifits of 'many eyes', however the view that there are 'strict' coding standards, infering code not written in that maner, will not be accepted, obviously means that they read through, and leave - probably ending up at manual's site if they are lucky. For PEAR & PHP its a loss, there is nothing wrong with this code, it's just not standardized, and the contributer looks at the standard and says - "well, have I got 4 hours or 2 days" (depending on size of code) to sort out all the various compatibility issues. so instead of being contributed it ends up on their hard drive. Someone else has to address the same problem, and ends up starting from scratch doing the same task..... So at present we have a disparate mess (perhaps a bit strong) of code residing all over the place, sourceforge, manual's site, (not to mention half a dozen extra great sites.) Is there a way to address - well kind off - this is still half baked, but may fly.... prePEAR (or prepare), a less strict repostitory that is set up on the assumtion that the packages will eventually be converted to PEAR standards, either by the author or another volunteer. In general anyone submitting a class library/set of files would be aware that the should have the intention of moving to the PEAR standards, eg. - basically the cosmetic standards of PEAR may/may not have been applied yet. -- this could include indentation, {} positioning, internal variable names etc., documentation..... - If and when it was moved to PEAR it would be backwardly compatibly with the 'prePEAR' library. As far as I can see (and Im sure every one find other issues with it :) - the only drawbacks are 1. that It would need a maintainer.. , and may a bit of a pain due to all those extra CVS accounts....... 2. the coding standard has one feature that may break BC.... (see below). ------------------------------- Studly Caps :) - probably the most controversial standard in the guide...... Love um or hate um - you will find that there are people who absolutly hate them, and these people __can not__ contribute to PEAR... I thought I would look at other language standards that are out there... - (Im sure there is more, and the list could go on forever...) Java - seems to specify Studly Caps Gnu C - specificly says NO to Studly Caps Perl - Says either is OK as long as you dont mix them in a single module. Delphi/Pascal - use the iPrefix = Hungerian MS standard.. This single condition in the codeing standard is the only one that is not cosmetic, but actually core to backward compatibility - if you write a large app in PHP, and use only the underscore_standard in all your files, but consider a few of the classes may be usefull to PEAR.. - then it could be near imposible to convert your whole applicatoin just so 3 or 4 classes could be contributed to PEAR. - how could anybody justify that as a task - whether done for commercial, or pleasure reasons......... I would suggest, and given those reasons that the Nameing convention be relaxed slightly - to say something along the lines of use either of these standards, but avoid mixing them in the same class/class set. Anyway thats a bit more than 2c Best Regards Alan