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

Hello, Karsten Kraus wrote: > > 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(). In manually written code I capitalize all words. Making the first word all in lower case is a Java mania that I fail to understand the point and not see why would that be more readable. Anyway, I can read and capitalization style, I don't know how can a normal person be so limited to not be able to read it. > 2. I'll have to care about case when PHP5 comes out, so why not start now? Zeev does not approve function name capitalization, so forget case sensitivity for PHP 5. > So I'm sure > my code will always work and the PEAR-Developers don't have BC-problems Zeev does not want PHP 5 function names to become sensitive precisely to avoid BC-problems, so it is one less problem for you to worry. > > 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 At least I am for the principle that no author should be excluded. If you are for segregation because of differences in style that says a lot about yourself. You are just confirming that PEAR developers want to make PEAR a repository that only an elite contributes too. > 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 What I proposed is that the style of each contributed class be preserved. > converting old code to PEAR-stlye can be annoying, but I believe it's worth > it. I suggest that you try to understand the reasons of why developers do not want to contribute before concluding that pushing PEAR style. > 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. It is your perception that it is wrong. If PHP did not allow both styles to be equivalent, only one style would valid. > 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. A lot of people do that. As I mentioned the PHP Classes Repository has 10 times more contributors than PEAR. Not everybody knows or uses both PHP Classes Repository and PEAR, so users are authors are missing a lot. > > 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. Of course it is. When you compile and run the same code written with different styles, the functionality is the same and style does not change anything. Users only care about what code does. > 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. For users, it does not matter how classes are written internally because that does not affect the way they have to be called. > 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. You are confusing users with hackers that want to change everybody's code. AFAIK, pleasing users is uncomparably more important than pleasing hackers because users are much more in number than hackers. Pleasing more users is more rewarding for authors than pleasing a bunch of hackers that just moan and groan about their style preferences. Regards, Manuel Lemos