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

i agree. i found that the solution for those who do not want to code PEAR strict (ie, hosting your classes wherever you want, and uploading a package.xml file... if i'm understanding this process correctly) was pretty good, and addresses a lot of the concerns of people with similar concerns as Conor: people who want tabs and who hate the "one true brace", but who also really appreciate the idea of the PEAR repository, and want to contribute. perhaps documenting that option on the site or in the FAQ should be a priority, so that these kinds of posts do not repeat as often. dietrich > -----Original Message----- > From: Karsten Kraus [mailto:Karsten.Kraus@swr3.de] > Sent: Thursday, November 22, 2001 9:22 PM > To: pear-general@lists.php.net > Subject: 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 > > > > > > > -- > 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 > >