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

Sorry for the really bad english, but it's quite late now ;-)) Karsten > -----Ursprungliche Nachricht----- > Von: Karsten Kraus [mailto:Karsten.Kraus@swr3.de] > Gesendet: Freitag, 23. November 2001 03:22 > An: pear-general@lists.php.net > Betreff: 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 > >