AW: [PEAR-DEV] Do PEAR Coding-Styles make sense? (was: Re: [Zend Engine 2] Constants (was: delete construct))

Hello Manuel, Hello list, hope you don't mind me changing the subject, but I didn't follow the original thread on the Zend-List and the new subject seems to be more appropriate to me. > Why? Would the code would stop being useful? I dare to say YES! (see below) > > I am not saying that there should be no rules, I am just saying that > some rules like function name case and fixed number of spaces for > indentation is not necessary. While I really don't care about that tabs over space-thingie, i'd insist on _ONE_ consistent naming-scheme for public functions, variables and constants. It makes life much easier for people like me who mainly use the PEAR-Classes as their 'toolbox' and time-savers than to create them (of course I will someday (i hope *g*)). I'd don't like to have one class have methods named Class1::doThis() and another with Class2::do_that(). > > Pushing a set of rules that adds no functionality to the code and > require the original contributor to spend even more time to adjust code > appearance, is highly counterproductive as many potential contributors > will simply not do it. I'm not so sure... until I started using the PEAR-Classes, I was using a complete different coding-style (\tfunction do_this() { ... ). I agree with you, that the PEAR-Style isn't the one and only Good ThingTM, but it is no problem to switch to them in most cases (I changed the function names in my current project with among 10-30 classes in about 4 hours). Besides - I think it's common that you create a class/package for your own need first in your own dirty an tricky way ;-) and later you have to clean up your code it and strip silly comments and make proper documentation and usage examples before you show them to the public anyway. Now you have to change the function names too, but it's worth it 'cause you make your stuff easier and better to use for others - but I have to admit, that until now I don't have commited anything to PEAR execpt my postings to this list ;-) > I think PEAR will never be as successful as for instance the PHP Classes > Repository or even CPAN for details like this because it is not > motivating for the original authors of the code. You have to provide so > much effort for such a little recognition. I don't think so. if the PEAR Installer will be as easy to use as e.g. ActiveState's PPM than many people will start using PEAR as their everyday time-saver... and they'll really appreciate a consistent API/naming-scheme. Bye Karsten P.S.: I personally don't like to use PHP-Classes, because I have to register for it, but perhaps that's just me