Re: Template Proposal
| From: | Lux | Date: | Thu, 08 Nov 2001 23:58:43 +0000 |
| Subject: | Re: Template Proposal | ||
| References: | 1 | Groups: | php.pear.dev |
| Request: | Send a blank email to pear-dev+get-2708@lists.php.net to get a copy of this message | ||
Richard Heyes wrote:
Lux wrote:On Thursday, November 8, 2001, at 04:02 PM, Richard Heyes wrote: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.Andrei Zmievski wrote:Why not? :)On Thu, 08 Nov 2001, Martin Jansen wrote:Why?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. :)
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).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.
Good. :) LuxI 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. :)
-- Richard Heyes "If you have any trouble sounding condescending, find a Unix user to show you how it's done." - Scott Adams