RE: [PEAR-DEV] Template Proposal
| From: | Dietrich Ayala | Date: | Fri, 09 Nov 2001 00:42:32 +0000 |
| Subject: | RE: [PEAR-DEV] Template Proposal | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-2710@lists.php.net to get a copy of this message | ||
+1
the 2 biggest reasons for me not being an active part of PEAR:
1. lack of tabs, "one true brace", etc. - coding according to PEAR style
would decrease my productivity.
2. PEAR *isn't* trying to be CPAN, illustrated wonderfully by the template
API debate (which also illustrated that PEAR is different things to
different people). After listening to the template debate, I'm favoring
choice over unified API; can't find enough reasons to *not* have several
PEAR template engines: different strokes fo different folks.
d.
> -----Original Message-----
> From: Lux [mailto:lux@simian.ca]
> Sent: Thursday, November 08, 2001 6:59 PM
> To: richard@phpguru.org
> Cc: pear-dev@lists.php.net
> Subject: Re: [PEAR-DEV] Template Proposal
>
>
> Richard Heyes wrote:
>
> > Lux wrote:
> >
> >
> >>On Thursday, November 8, 2001, at 04:02 PM, Richard Heyes wrote:
> >>
> >>
> >>>Andrei Zmievski wrote:
> >>>
> >>>
> >>>>On Thu, 08 Nov 2001, Martin Jansen wrote:
> >>>>
> >>>>>That's exactly where to problems arise: The function names in Smarty
> >>>>>don't correspond to the PEAR coding standards ;-). But maybe we can
> >>>>>also find a solution for this.
> >>>>>
> >>>>Yeah, make an exception. :)
> >>>>
> >>>Why?
> >>>
> >>Why not? :)
> >>
> >
> > Because a coding standard is just that, a standard. Andrei commented
> > previously that there are so many standards you can choose to
> support, well
> > that's wrong. There are usually a single set of standards, and the thing
> > that varies is the implementations of those standards. Browsers are of
> > course the classic example. Making exceptions to the rule are
> one way of how
> > these various implementations come about.
> >
>
> >
> >>As long as they provide ample documentation to refer to, does it really
> >>matter what the functions are called? Unless they are simply too
> >>unclear and can be improved in that regard, I would leave them. If
> >>people have already been coding with the old function names, it could
> >>end up being an unreasonable or wasted investment of time to go through
> >>all their code and update things.
> >>
> >
> > I think having all the PEAR code look as similar as possible is a great
> > thing and makes reading the code much easier.
> >
>
>
> My code breaks PEAR compliance in quite a few noticeable ways:
> - I use tabs. The argument for them is that sure you can set your
> editor to automatically insert spaces, but backspacing 3 or 4 spaces
> requires 2 or 3 extra backspace keystrokes than with tabs. I believe in
> the conservation of keystrokes (I'm also probably one of very few that
> actually like unreadable Perl variables like $!, $_ and $|, although
> admittedly they don't lend themselves well to legibility).
> - I put extra spaces all over (ie. "$obj->meth (array ($foo, $bar), date
> ('Y-m-d'));"), which is discouraged by PEAR standards, but I find it
> significantly increases legibility.
> - I _always_ put my curly braces on the same line as the while, if,
> function, etc. PEAR seems to suggest this for most cases, except
> function definitions.
> - you get the point :)
>
> I've found myself in more collaborative coding situations lately, and it
> surprised the hell out of me how much positive feedback I get on my
> coding style. It's strange and kind of awkward to say thank you to.
>
> I guess what I'm saying is that I would have defined much different
> rules (and no, I wouldn't have simply said "use tabs" :)). I would've
> said, "use appropriate indentation", "use ample spacing" and "put
> your
> curly braces where you want, but don't exclude them".
>
> Then again, I'd allow for exceptions to that last one if the following
> was possible in PHP: "$var = 'boo' if ($blah);"
>
> And I don't mind the "foo : bar ? asdf" syntax either.
>
> Also, this doesn't solve the problem of people who would have to migrate
> their existing code to the new PEAR-ized APIs, especially with classes
> like Smarty where a significant user-base is already established.
>
> Also, Ruby coders tend to use the some_method () syntax instead of
> someMethod (), and I think it comes down to preference really. Ruby is
> arguably the most legible language on the scene, so I think it makes a
> decent example in this regard. Whereas Java uses the someMethod ()
> syntax moreso, and I can't stand looking at Java code. It's too
> "sentense-y", too long horizontally. Code should be short on width, and
> well-spaced out (and well commented).
>
> >
> >>I should apologize, I'm not trying to complain or spark a debate, I just
> >>tend to rant too much. ;)
> >>
> >
> > Debate is what we're here for. :)
>
>
> Good. :)
>
> Lux
>
> >
> > --
> > Richard Heyes
> > "If you have any trouble sounding condescending,
> > find a Unix user to show you how it's done." - Scott Adams
> >
> >
> >
> >
> >
>
>
>
> --
> 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
>
>