Re: I can't believe it...

On Thu, Nov 22, 2001 at 11:33:01PM +0000, Conor Kerr wrote: > Hi Alexander, > > > Thats not exactly backwards, it's a matter of style. I definately prefer > > spaces, so I don't really agree with you. > > Writing a monolithic application in assembly is also a matter of style. No, I disagree. Style, in the context of this discussion, refers specifically to the formatting and coding conventions that are followed in the production of code. > Does that make it sensible? I would venture that instead it makes it > ridiculous. 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. > 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. > > The coding standards are very strict, but that's what PEAR is for. PEAR is > > meant to be a rather small repository for highly reusable, high quality > > classes, standard classes, and the standard also applies to the coding style. > > 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. > can't. Spaces will give the maximum compatability across all text > editors but the benefits of tabs outweigh this as they give the > individual the choice without affecting anyone else. Text editors which > can't cope should be moved out of the seventies and into the 21st century > or not used to create reusable classes. Spaces have the benefit of guaranteeing that the code is displayed in the same format regardless of your editor's tab stops. > > > It saddens me that so many programmers today have no clue about > > > the importance of usability and flexibility, mostly in the Unix and > > > windoze camps. :( > > > > Maybe you're misinformed about the goals of PEAR. > > My reactionary post was so inflammatory because of the sheer irony that > a project like PEAR has a particular concept at heart which is in complete contrast to the > spirit of the goals! It insists on an unflexible method > for textual formatting when there is a highly usable, configurable and > personal alternative. I apologise for my tone, I just got a bit heated, > I get so frustrated with a lot of the bad ideas I see around me that > affect what I want to do (in this case help out). :( I again fail to see how the strict standards that the PEAR project follows is in contrast to the overall goals of the project. > > > I, unfortunately, will not be contributing to the PEAR project as long > > > as arcane concepts are employed. > > > > What? Standards are arcane? > > The use of spaces for formatting has long been superseded as a standard, > just look at HTML - you can't even have two spaces in a row, the > concepts behind this decision are especially applicable to source code. The fact that repeated white space is ignored in HTML has nothing at all to do with the percieved inferiority of spaces over tabs. > > > Whoever came up with those coding standards has a LOT to learn about > > > effective computing. > > > > PEAR is not meant to be developed easily, quite the opposite. It's meant to > > be used easily and an example for people to learn from. > > That's the way I write all my software, when looking at all the various > methods of coding it is the one that shines out as the right way to do > things. In the same way so does the use of tabs over spaces, I was > absolutely stunned that whoever came up with the noble concept of PEAR > couldn't see that. 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. Since attacking the PEAR standard as being archaic is fruitless... 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.