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

Hi Manuel, > But at least until PHP 5, function and variable names are case > insensitive. What does it matter the case that the original author uses, > when you can use whatever case you want for the function names!? 1. I as user find thisDoesThat() easier to remember and to read than thisdoesthat(). 2. I'll have to care about case when PHP5 comes out, so why not start now? So I'm sure my code will always work and the PEAR-Developers don't have BC-problems > You don't have a problem but other authors have. Obviously some have, some not - that's life. So they don't contribute, okay. To be honest, I think if all that keeps people from contributing are some coding-standards - even that strange space over tabs rule - I'm not sure if I wan't to use their code, because to me it seems their ability to write good code must depend on coding style which can't be a good thing. IMPORTANT: I'm talking about newly written code, not about existing code which must be ported, I can see that converting old code to PEAR-stlye can be annoying, but I believe it's worth it. But if your not able to write a good makeMeHappy()-Funktion but are able to write a better makemehappier()-Funktion I think there is something wrong. My personal conclusion: If standards that are good for usability and maintance hinder your ability to write good code - well than go and publish your code somewhere else, or find someone which converts them for you. > > It is already a bad thing for many authors to give up full control over > the development of their code, they even have to put up with some > needless conventions just to have their code accepted in PEAR?! For many > authors this is a sacrifice that they do not want to do because there is > nothing wrong with their code! Changing indentation and name convention > adds absolutely no functionality to that code. Again: As I tried to tell you, functionality of code isn't everything. Especially in packages which build something like an API for programmers - and I think that's what PEAR will and should be - usability is almost as important as functionality. The problem with CPAN is that there is very good code in it, but every module has its own 'syntax' an specialties. This make it hard (especially for beginners) to use this code, even if its of superb qualitiy when you just look at functionality. Bye Karsten