Re: 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