Re: RFC: coding standards document

I dig 4-space tabs. simple, the display is always the same :) _a -- Alex Black, Head Monkey enigma@turingstudio.com The Turing Studio, Inc. http://www.turingstudio.com vox+510.666.0074 fax+510.666.0093 Saul Zaentz Film Center 2600 Tenth St Suite 433 Berkeley, CA 94710-2522 > From: andi@zend.com (Andi Gutmans) > Newsgroups: php.pear > Date: 16 Dec 2000 22:52:35 -0800 > Subject: Re: [PHP-PEAR] RFC: coding standards document > > Stig, > > I know this reasoning. That's why I mentioned before that it will only > effect a small amount of code. But again, if you set tabsize to 4 as a > standard it would do the trick. The same way as if you set tabsize to 4 > spaces. > But if the PEAR people prefer this it's your call. > Andi > > At 03:09 AM 12/17/00 +0100, Stig S. Bakken wrote: >> Andi, >> >> I've included my last mail to the thread where we discussed this a week >> or two back. See the "RFC: coding standards document" thread for the >> details. >> >> - Stig >> >> Chuck Hagenbuch wrote: >>> >>> Quoting Ulf Wendel <ulf.wendel@phpdoc.de>: >>> >>>> Is this a request for comment or a standard... >>> >>> It is a proposed standard. >>> >>>>> ------------- >>>>> [1] Indenting >>>>> ============= >>>> >>>>> Use an indent of 4 spaces, with no tabs. If you use Emacs to edit PEAR >>>> >>>> Tabs, size: 4 spaces as for the PHP C code. >>>> >>>>> ------------------------ >>>>> [4] Function Definitions >>>>> ======================== >>>>> >>>>> Function declaractions follow the "one true brace" convention: >>>> >>>>> function fooFunction($arg1, $arg2 = '') >>>>> { >>>> >>>> function fooFunction($arg1, $arg2 = '') { >>> >>> Both of these could go either way, but I've had several people agree >> with #4 as >>> written, and I think Stig weighed in in favor of spaces instead of tabs. >> >> I can explain my reasoning a bit. My main problem with tabs is that >> different editors have different tab widths, and even if you can >> configure this, it's nice with source that is nicely formatted without >> special editor configuration. Take this simple example with 5-space >> tabs: >> >> function foobar($arg) >> { >> [tab]printf("%d<BR>\n", >> [tab][tab] $arg); >> } >> >> In an editor with 8-space tabs, it will be: >> >> function foobar($arg) >> { >> printf("%d<BR>\n", >> $arg); >> } >> >> And with 2-space tabs: >> >> function foobar($arg) >> { >> printf("%d<BR>\n", >> $arg); >> } >> >> If we just stick to spaces, it will look the same. I hope all the >> editors that are in use here can use spaces instead of tabs. >> >> - Stig >> >> >> >> Andi Gutmans wrote: >>> >>> Stig, >>> >>> I think it should be the same as the PHP C code. Is it a good idea to have >>> two different coding standards? >>> I think having tab's is a very big benefit (it rarely is a nuisance >>> although it does happen). It is much easier to adjust the code's >>> indentation when you modify/rip it apart :) >>> In any case, the same way as people will be defining in their editor that >>> tab == 4 spaces they can define that the default tab is 4 spaces large. So >>> in both cases you need to configure your editor. >>> If everyone reached a consensus then I won't ruin it but I just want to >>> share my opinion. And I'm going to shoot people who commit non-tabified >>> code (i.e. spaces) to the C PHP :) >>> Andi >>> >>> At 08:15 PM 12/16/00 +0100, Stig S. Bakken wrote: >>>> Andi, >>>> >>>> I find that relying on tabs is a bad idea, since the default tab width >>>> varies from editor to editor. We just had the same discussion on this >>>> list, and the consensus was to not use tabs. >>>> >>>> - Stig >>>> >>>> On Sat, 16 Dec 2000, Andi Gutmans wrote: >>>> >>>> | Shouldn't the indentation of PEAR be the same as of PHP? >>>> | A tab "represents" four spaces but we don't do a tab->spaces >> conversion but >>>> | keep them as tabs. >>>> | >>>> | Andi >>>> | >>>> | At 01:18 AM 12/16/00 +0200, Martin Pedak wrote: >>>> | >Chuck Hagenbuch wrote: >>>> | > >>>> | >>Quoting Martin Pedak <qwerty@webmedia.ee>: >>>> | >> >>>> | >>>What is what? >>>> | >>>> >>>http://utvikler.start.no/code/php_coding_standard.htm >>>> and the >>>> | >>>attachented CODING_STANDARS.txt >>>> | > >>>> | >>The attached file is just a link (broken, it seems) to some >>>> company's >>>> | >>standard >>>> | > >>>> | >Sorry, put the "l" (L) to the end of the URL and it works. (Copy >>>> & >>>> Paste :)) >>>> | >>>> >http://utvikler.start.no/code/php_coding_standard.html >>>> | > >>>> | >Martin Pedak >>>> | > >>>> | > >>>> | >-- >>>> | >PHP Extension and Add-on Repository (PEAR) mailing list. >>>> | >Documentation can be found at >>>> http://pear.php.net/doc/pear.html >>>> | >To unsubscribe, e-mail: php-pear-unsubscribe@lists.php.net from the >>>> | >mail address you subscribed with. >>>> | >>>> | --- >>>> | Andi Gutmans <andi@zend.com> >>>> | http://www.zend.com/ >>>> | >>>> | >>> >>> --- >>> Andi Gutmans <andi@zend.com> >>> http://www.zend.com/ >>> >>> -- >>> PHP Extension and Add-on Repository (PEAR) mailing list. >>> Documentation can be found at >>> http://pear.php.net/doc/pear.html >>> To unsubscribe, e-mail: php-pear-unsubscribe@lists.php.net from the >>> mail address you subscribed with. > > --- > Andi Gutmans <andi@zend.com> > http://www.zend.com/ > > -- > PHP Extension and Add-on Repository (PEAR) mailing list. > Documentation can be found at http://pear.php.net/doc/pear.html > To unsubscribe, e-mail: php-pear-unsubscribe@lists.php.net from the > mail address you subscribed with. >