Re: Template Proposal

TABS-or-SPACES when are we getting over this? is this topic now coming up every once in a while? functionality is more of importance > >> NO! We need the coding standards - although I would like to see > >> tabs used > >> instead of spaces - that way when you're working on a class, if > >> you like > >> your indentation set to 10 spaces you just alter the tab stop. > >> If you like > >> it one space, you alter the tab stop. The next developer can > >> set it to exactly what he wants. I think you get my meaning :-) > > > > Yeah, I get your idea. But see the following example: > > > > <?php > > foo("value1", > > "value2" > > ); > > ?> > > > > This snippet only looks good with spaces or with a tab width set > > to 4 spaces. When using a different tab width, "value2" will be > > indented differently => tabs are evil :-). > > Then add more spaces. > > <?php > > foo ( > "value1", > "value2" > ); > > ?> > > The 'evil' tab doesn't 'get us' that way, and it's cleaner to > read. > > My argument for less restriction on formatting rules is simply that > they were chosen based on the subjectivity of the few who started > PEAR and may not correspond to the way a lot of developers work. > I've been coding a certain way for years now. Nobody's ever > complained. In fact, they've done quite the opposite. I would > find myself less productive if I had to remove the spaces between > my method calls and their parentheses "methodName() v.s methodName > ()", or if I had to start putting my curly braces on the line after > the function declaration. I think the former in the above example > detracts from legibility, yet it is the PEAR standard. Or if I had > to switch to spaces. I've tried that, and it sucked. So I'm a bit > of stickler on my personal coding preferences. > > I think we can set guidelines that are still clear enough, yet > flexible enough to accommodate slight differences in coding style, > that some joe can't come along with indents of 1 space and say > "here ya go". Actually, the first time I read about PEAR and saw > all those formatting rules, I said to myself "fuck that" and didn't > bother looking at it for quite a while afterwards. > > And as for ensuring it's a high quality repository, keep the > approval process. Don't let just any joe go committing new Forums > and such that have no place in PEAR, or some class that is only > half functional and kind of shifty. I think it's a waste of time > arguing over whose template engine should become the standard. The > "we already have one of those, sorry" rule may only end up hurting > PEAR in the long run, when some guy with a new class moseys on in > and is refused because we don't need another template engine, and > his engine ended up having a really cool idea we didn't notice to > consider so we lose out. > > Lux > > > - Martin > > > > > > > > -- > > PEAR Development Mailing List (http://pear.php.net/) > > To unsubscribe, e-mail: pear-dev-unsubscribe@lists.php.net > > For additional commands, e-mail: pear-dev-help@lists.php.net > > To contact the list administrators, e-mail: > > php-list-admin@lists.php.net -- Wolfram