AW: [PEAR] I can't believe it...

Hi there, i am quite new to this list (about 2 weeks). I subscribed mainly because I wanted to be up to date with the latest development of the pear-classes because I use them as base for one of my projects. I see some importance in the discussion about codingstandards and styleguides... but to be honest, its getting boring. Conor, I agree with you, that some of the standards seem to be quite, let's say special and I don't think, that perl code is of lower quality even though the cpan-standards aren't that strict. I don't use spaces for indenting too - but just because their the default setting in most windows-editors I know. But I know at least two good editors (med and komodo) which can work with both tabs and spaces. But that's not the point. Most of the core-developers of the PEAR-Repository seem the be quite happy with those standards and have reasons, why they want the standards like that. I see no good in discussing standards before we really have done some contributions to the repository. BTW. Would you (Connor) like to reformat all your code in the PEAR-Repository just because I don't like function names like 'isError()', which you may find really a good thing. So, I use wrapper-functions like 'is_error()' for my projects or convert existing classes and code to fit the naming scheme and you could use an editor which can convert tabs to spaces or use a filter as James mentioned. Conclusion: Good and useful code doesn't rely on formatting, but maintainers do. (<< Tabs *G*) And life is to short for argueing about \s) Bye Karsten > -----Ursprungliche Nachricht----- > Von: Conor Kerr [mailto:conor@ceonsystems.com] > Gesendet: Freitag, 23. November 2001 02:22 > An: pear-general@lists.php.net > Betreff: Re: [PEAR] I can't believe it... > > > Hi, > > > Well, your analogy is indeed ridiculous. You'd be silly to code a giant > > app in assembly. But your analogy is also irrelevant. It's either a red > > herring or a straw man, but in any case, it's not a good analogy. > > I don't think my analogy is irrelevant. One of the main reasons for not > coding an application in assembly is that it can be very hard to edit as > it is generally written in a fixed format, languages like PHP are much > easier to write in as you don't have to worry about column numbers etc, > you are concerned more with the structure of the program than the source. > That doesn't mean however that you don't keep the source neat and nicely > structured. > > > > You prefer spaces so you advocate forcing a particular hard-coded > > > formatting on everyone else. :( > > > > When you work in an organization, as a member of a team of > developers, you > > often have to subvert your preferred coding style in order to > conform with > > the established standard. Spacing between parentheses, curly brackets, > > variable names, and indentation are all subject to some > overriding standard. > > I understand that, I am in no way saying that a standard for formatting > of code isn't important. However, the issue we are actually talking > about is of no real relevance to the actual readability of any code that > the reasoning behind increasing a programmer's workload has to be > examined. I would say that the solution specified as the only solution > just can't be justified given the alternatives. > > Print out a page of code where 8 spaces have been used to indent blocks > and then print out a page of the same code where a tab is used to indent > blocks and the editor's tab width setting is set to 8 spaces, they will > look identical. However, the code for one of those pages will take much > longer to edit than the code for the other due to the 7 extra keystrokes > that have to be used. That's not my only point but it is an essential > one. > > > > That is indeed a very noble and valuable concept, exactly the kind of > > > thing that I want to see more of these days. Unfortunately it > is flawed > > > at heart by the coding standards. Tabs can be reset and > resized, spaces > > > > I fail to see your point... the statement was that PEAR has a > very specific > > purpose. Their strict coding conventions that the project uses > is in-line > > with their other goals. > > PEAR aims to create reusable classes, a concept which comes from the > idea of flexibility and ease of use for the user yet the source has to > be written in an inflexibly formatted manner, the formatting is > hard-coded. A project which aims to make things easier for the user > makes things harder for the developer in an area where the difference > between the hard and easy methods can not be told by looking at the > source (when tabs are set to a particular size in the editor). This > seems to contrast to me. > > > I again fail to see how the strict standards that the PEAR > project follows > > is in contrast to the overall goals of the project. > > It's not the fact that it uses strict standards, it's that it > excludes a more > flexible style at the behest of a less flexible one when both can give > the same result. > > > The fact that repeated white space is ignored in HTML has nothing at all > > to do with the percieved inferiority of spaces over tabs. > > The reasoning behind this move was that formatting and content were to > be as seperate as possible. Experience has taught us that code has to > be structured to be readable but, just like with HTML, the actual laying > out of the code should give as much control to the individual as is > possible. Tabs give a certain amount of control to the user for > indentation, spaces withdraw quite a bit of control for indentation. > > We have to move beyond the old "standard" practices of the past whenever > a more logical and suitable standard becomes available. > > > I think that the biggest issue here is that the choice of using > spaces over > > tabs is in direct contrast to a coding style that you prefer. > > It's not just that I prefer it, it can be shown to be a much better > solution. Flexibility is extremely important, everything in computing > used to be hard-coded, now everything aims to be as reusable as possible. > I don't think that people simply prefer things to be reusable, I think > people realise that they are better that way. > > A lot of people find it hard to let go of conventions of the past when > there is a better, more flexible modern solution. I wouldn't have a > problem with that (they can do extra work if they like ;) ) if it wasn't > for the fact that these people are dictating what everyone else has to > do. > > > Since attacking the PEAR standard as being archaic is fruitless... > > I don't think it is! If I can help people question the wisdom of their > ways then I've done something worthwhile. :) > > > perhaps even a bit unreasonable, and since you seem adamant about your > > chosen coding style, perhaps there's some compromise that you could > > make that would allow you to both contribute to the project yet > > continue to use tabs. Perhaps you could write some filter to > > automatically convert sequences of spaces to tabs and then reverse the > > process when you plan to submit code. There might even be an editor > > on your preferred platform that already has this kind of functionality. > > I'm certain that there are other solutions that would accomplish the > > same goals that I haven't even thought of. > > That kind of thing would work but my point is that it shouldn't have to > be that way, in a company there wouldn't be a choice as you would just > have to accept things for the way they were, but in an open-minded > forward looking project I feel that there should be a chance for > change. :-) > > All the best... > > Conor > > > -- > PEAR General Mailing List (http://pear.php.net/) > To unsubscribe, e-mail: pear-general-unsubscribe@lists.php.net > For additional commands, e-mail: pear-general-help@lists.php.net > To contact the list administrators, e-mail: php-list-admin@lists.php.net > >