Example, the next generation (the extended cut)
Paladin
/**
* Short File Description (Required)
*
* Long File Description. It's optional. See follow-on message for
more detailed explanation of
* some of the terms encountered here.
*
* @version $Id $ [required]
* @category Joomla [Optional, serves no visible purpose]
* @package Joomla.Framework [Optional, should only exist if non-
class items are present]
* @subpackage ThisExt [Optional, should only exist if non-class
items are present]
* @author name [Should not be used for core files]
* @copyright Copyright (C) 2005 - 2009 Open Source Matters, Inc. All
rights reserved.
* @since 1.0 [Optional]
* @deprecated 1.5 [Optional]
* @license GNU General Public License version 2 or later; see
LICENSE.txt
* @link [Optional, core must link to Joomla URL]
* @uses [Optional]
* @example path/to/example.php [Optional]
* @filesource [Optional]
* @internal [Optional]
* @final [Optional, as PHP5 subsumes it]
* @todo [Optional]
*/
// No direct access
defined('JPATH_BASE') or die;
/**
* Short Description
*
* Optional longer description of the class
*
* @package Extensions
* @subpackage ThisExt
* @see [Optional]
* @uses [Optional]
* @link [Optional, core must link to Joomla URL]
* @since 1.0 [Optional]
* @deprecated 1.5 [Optional]
* @ignore [Optional]
* @internal [Optional]
* @method [Optional]
* @tutorial [Optional]
* @access public | private | protected [Optional, as php5 subsumes
these]
* @abstract [Optional, as php5 subsumes it]
* @todo [Optional]
*/
class JSomething extends JSomethingElse
{
/**
* @var float $variable Description of staticvariable
* @see [Optional]
* @uses [Optional]
* @link [Optional, core must link to Joomla URL]
* @since 1.0 [Optional]
* @deprecated 1.5 [Optional]
* @ignore [Optional]
* @internal [Optional]
* @static [Optional, as php5 subsumes it]
* @todo [Optional]
*/
static $staticvariable = 12.6;
/**
* @var string $variable Description of variable
* @see [Optional]
* @uses [Optional]
* @link [Optional, core must link to Joomla URL]
* @since 1.0 [Optional]
* @deprecated 1.5 [Optional]
* @ignore [Optional]
* @internal [Optional]
* @access public | private | protected [Optional, as php5 subsumes
it]
* @todo [Optional]
*/
public $variable = 'whatever';
/**
* @var bool $protected Description of protected
* @see [Optional]
* @uses [Optional]
* @link [Optional, core must link to Joomla URL]
* @since 1.0 [Optional]
* @deprecated 1.5 [Optional]
* @ignore [Optional]
* @internal [Optional]
* @access public | private | protected [Optional, as php5 subsumes
it]
* @todo [Optional]
*/
protected $protected = false;
/**
* @var int $privatevariable Description of privatevariable
* @see [Optional]
* @uses [Optional]
* @link [Optional, core must link to Joomla URL]
* @since 1.0 [Optional]
* @deprecated 1.5 [Optional]
* @ignore [Optional]
* @internal [Optional]
* @access public | private | protected [Optional, as php5 subsumes
it]
* @todo [Optional]
*/
private $_privatevariable = 12;
/**
* Short Descriptor
*
* Optional Long description
*
* @param string $one description.
* @param mixed $two description.
*
* @return void
* @throws JException
* @see [Optional]
* @uses [Optional]
* @link [Optional, core must link to Joomla URL]
* @since 1.0 [Optional]
* @deprecated 1.5 [Optional]
* @ignore [Optional]
* @internal [Optional]
* @tutorial [Optional]
* @access public | private | protected [Optional, as php5 subsumes
these]
* @abstract [Optional, as php5 subsumes it]
* @todo [Optional]
*/
public function methodOne( $one, $two )
{
// short if format
if (condition()) {
&$do_something;
}
// Longer if format
if (condition())
{
do_something();
do_something_more();
}
else
{
do_something_else();
}
if (condition()) {
do_something();
}
else if (condition())
{
do_something_here();
}
else
{
do_something_else();
}
}
/**
* Short Descriptor
*
* Optional Long description
*
* @param array $one description.
*
* @return bool
* @see [Optional]
* @uses [Optional]
* @link [Optional, core must link to Joomla URL]
* @since 1.0 [Optional]
* @deprecated 1.5 [Optional]
* @ignore [Optional]
* @internal [Optional]
* @tutorial [Optional]
* @static [Optional, as php5 subsumes it]
* @access public | private | protected [Optional, as php5 subsumes
these]
* @abstract [Optional, as php5 subsumes it]
* @todo [Optional]
*/
static function staticMethod( $one )
{
foreach ($one as $key => $value) {
$one[$key] = $value / 2;
}
return true;
}
/**
* Short Descriptor
*
* Optional Long description
*
* @param string $oneArgumentWithLongName description.
* @param mixed $two A longer description that for readability
* will wrap to the following line.
*
* @return string
* @see [Optional]
* @uses [Optional]
* @link [Optional, core must link to Joomla URL]
* @since 1.0 [Optional]
* @deprecated 1.5 [Optional]
* @ignore [Optional]
* @internal [Optional]
* @tutorial [Optional]
* @access public | private | protected [Optional, as php5 subsumes
these]
* @abstract [Optional, as php5 subsumes it]
* @todo [Optional]
*/
protected function aMethodWithLongNameAndArgumentList
($oneArgumentWithLongName,
$two ) {
switch ($two) {
case 1:
do_something();
break;
case 2:
do_something_different();
break;
default:
handle_default_case();
break;
}
return (string) $value;
}
/**
* Short Descriptor
*
* Optional Long description
*
* @param int $one description.
*
* @return int
* @see [Optional]
* @uses [Optional]
* @link [Optional, core must link to Joomla URL]
* @since 1.0 [Optional]
* @deprecated 1.5 [Optional]
* @ignore [Optional]
* @internal [Optional]
* @tutorial [Optional]
* @access public | private | protected [Optional, as php5 subsumes
these]
* @abstract [Optional, as php5 subsumes it]
* @todo [Optional]
*/
private function _method3( $one )
{
while ($one > 0) {
$one -= 1;
}
return (int) $one;
}
}
Niels Braczek
Looks good, but why do you introduce
> // Longer if format
> if (condition())
> {
> do_something();
> do_something_more();
> }
> else
> {
> do_something_else();
> }
now? AFAIR there was one single vote *for* it, all other prefer the PEAR
style...?
Regards,
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Jeremy Huntwork
> // short if format
> if (condition()) {
> &$do_something;
> }
Does the fact that there are tabs throughout this example also mean
that they are part of the proposed standard?
Jeremy Huntwork
LightCube Solutions
http://www.lightcubesolutions.com
Paladin
First, used tabs again, which don't translate well to email/browser, I
know, but neither does space unless you force your email client into
monospaced font, so it's lose/lose.
Second, included almost every known docblock tag in this run (at least
99.44% of the ones likely to be used outside of testing) which is what
makes it long. The vast majority of these tags are optional, so let me
boil it down in this "annotated" version (presentation suggestions in
final paragraph):
NOTE: speed kills. In my haste I note I left in the param variable
name in the first posting, which the tenor of the discussion was going
against. I've removed it in the annotated version below.
Means Short file description, version, copyright and license are the
only required tags in the file docblock. Package and subpackage are
optional and should be used if there are elements in the file that are
not part of a class (loader.php comes to mind immediately as a file
that fits into this category, but I think even the "defined or die"
code in most files may be enough to trigger it in phpdoc). I really
don't see a use for category in the Joomla context, but since it's
semantically a collection of packages, I thought it should precede
package if present (same treatment for author before copyright, noting
that author should not be used for joomla core). I've tried to be
logical and consistent about the order, but now that I look at it
again, perhaps license after copyright is a more logical order.
Any tags I've not accounted for may be used, but only after the last
of these tags.
>
> // No direct access
> defined('JPATH_BASE') or die;
>
> /**
> * Short Description
> *
> * Optional longer description of the class
> *
> * @package Extensions
> * @subpackage ThisExt
> * @see [Optional]
> * @uses [Optional]
> * @link [Optional, core must link to Joomla URL]
> * @since 1.0 [Optional]
> * @deprecated 1.5 [Optional]
> * @ignore [Optional]
> * @internal [Optional]
> * @method [Optional]
> * @tutorial [Optional]
> * @access public | private | protected [Optional, as php5 subsumes
> these]
> * @abstract [Optional, as php5 subsumes it]
> * @todo [Optional]
> */
For class docblock, Short description, package and subpackage are the
only required tags. Perhaps subpackage even should drop to optional.
Tried to keep similar order for tags in common with file.
> * @param string description.
> * @param mixed description.
I realized as I was making this, I may still be confused on brace
style, so this is what I *think* the hybrid style mentioned was.
Please correct me if not right. It's not PEAR, I know.
Pretty much the rest of the file is either as before or the
differences have been discussed above.
>
> /**
> * Short Descriptor
> *
> * Optional Long description
> *
> * @param array description.
> * @param string description.
> * @param mixed A longer description that for readability
> * @param int description.
> *
> * @return int
> * @see [Optional]
> * @uses [Optional]
> * @link [Optional, core must link to Joomla URL]
> * @since 1.0 [Optional]
> * @deprecated 1.5 [Optional]
> * @ignore [Optional]
> * @internal [Optional]
> * @tutorial [Optional]
> * @access public | private | protected [Optional, as php5 subsumes
> these]
> * @abstract [Optional, as php5 subsumes it]
> * @todo [Optional]
> */
> private function _method3( $one )
> {
> while ($one > 0) {
> $one -= 1;
> }
>
> return (int) $one;
> }
>
>
>
> }
Again, any tags not listed are just dropped in a heap at the end, in
whatever order. If there's one I haven't accounted for, let me know
what it is and where it goes. If I'm listing tags we really don't care
about the order for, let me know and I'll drop them from here.
As for publication, It would seem to me the most accessible way to
present these tags would be with a different contrast on the
background for all optional tags, making it immediately clear the file
won't be filled with 1087 docblock comments. As an alternative, we
could present a file only with the required docblocks, and let people
writing code use the phpcs joomla coding standard use it to tell them
how their docblocks should be rearranged. A bit frustrating for them,
yes, but makes the initial file less daunting. Or use javascript to
show/hide optional docblock tags in the web page.
Rafael Diaz-Tushman
if (condition())
{
do_something();
do_something_more();
}
else
{
do_something_else();
}
--
Rafael Diaz-Tushman, President & CEO
Dioscouri Design: Form and Function
www.dioscouri.com
www.twitter.com/dioscouri
Christophe Demko
// Longer if format
if (condition())
{
do_something();
do_something_more();
}
else
{
do_something_else();
}
wrote:
> lines for control structures like that. So, +1 for:
>
> // Longer if format
> if (condition())
> {
> do_something();
> do_something_more();
> }
> else
> {
> do_something_else();
> }
>
> Cheers!
> --
> Rafael Diaz-Tushman, President & CEO
> Dioscouri Design: Form and Functionwww.dioscouri.comwww.twitter.com/dioscouri
>
Ian MacLennan
and nobody really refuted your logic?
It seemed sensible to me. I would be comfortable with it.
Ian
Jeremy Huntwork
> +1 for
> // Longer if format
> if (condition())
> {
> do_something();
> do_something_more();
> }
> else
> {
> do_something_else();
> }
If there's a vote going on, then:
-1 for the above.
Paladin
On Nov 2, 12:27 pm, Jeremy Huntwork <jhuntw...@lightcubesolutions.com>
wrote:
> Does the fact that there are tabs throughout this example also mean
> that they are part of the proposed standard?
preferred. The codesniffer I'm working on allows both with equal
facility, so long as the indent levels are four spaces. phpcs requires
a "--tab-width=4" option to accept them, but will accept them.
Jeremy Huntwork
> IIRC, the position is tabs should be allowed, not that they are
> preferred. The codesniffer I'm working on allows both with equal
> facility, so long as the indent levels are four spaces. phpcs requires
> a "--tab-width=4" option to accept them, but will accept them.
Excellent, thanks for the reply.
Paladin
On Nov 2, 12:18 pm, Niels Braczek <nbrac...@bsds.de> wrote:
> Paladin schrieb:
>
> Looks good, but why do you introduce
>
> > // Longer if format
> > if (condition())
> > {
> > do_something();
> > do_something_more();
> > }
> > else
> > {
> > do_something_else();
> > }
>
> now? AFAIR there was one single vote *for* it, all other prefer the PEAR
> style...?
style than PEAR is, and there were at least two people who preferred
it publicly first time around, one of whom was the project lead. At
least that was my impression.
I'm willing to work with any brace style, but I want to "enshrine" the
one the dev team most prefers, so please, if I'm wrong about this, let
me know.
Paladin
On Nov 2, 1:00 pm, Ian MacLennan <ian.maclen...@joomla.org> wrote:
> I thought you had argued in favour of parameter names in the doc blocks
> and nobody really refuted your logic?
sensing resistance from Andrew and Chris at the least and got the
impression Louis was on board with Chris, which puts a lot force
behind leaving it out. Maybe I'm bending over backwards a little on
this point; if so, it's only because I don't want to add things
without seeing more support for it than opposed to it.
Niels Braczek
> On Nov 2, 1:00 pm, Ian MacLennan <ian.maclen...@joomla.org> wrote:
>> I thought you had argued in favour of parameter names in the doc blocks
>> and nobody really refuted your logic?
>
> You are half right. I am definitely in favor of them. But I was
> sensing resistance from Andrew and Chris at the least and got the
> impression Louis was on board with Chris, which puts a lot force
> behind leaving it out.
I strongly recommend to keep the variable names in the docblock. It is
the only sign showing, that the docblock is in sync with the method.
Regards,
Niels
Andrew Eddie
I honestly don't know which is better or worse.
Regards,
Andrew Eddie
http://www.theartofjoomla.com - the art of becoming a Joomla developer
2009/11/3 Paladin <arlen....@gmail.com>:
Andrew Eddie
>
>
> Because it was closer to the already documented but currently ignored
> style than PEAR is, and there were at least two people who preferred
> it publicly first time around, one of whom was the project lead. At
> least that was my impression.
>
> I'm willing to work with any brace style, but I want to "enshrine" the
> one the dev team most prefers, so please, if I'm wrong about this, let
> me know.
As far as I can remember it's always been the brace on the new line
(for Mambo and Joomla) and then the hybrid was introduced in 1.5.
"Back then" I had based in on the PEAR standard but it changes over
the years (so don't get too hung up on PEAR because it does move).
What I see a lot is when you have the brace on the one line, and then
a block of code, devs put in a new line to provide readable space. In
my opinion, why not just put the brace on the new line _shrug_. Eg:
if (condition) {
many
lines
of
code
}
Makes more sense to just do:
if (condition)
{
many
lines
of
code
}
Personally I think this forces extra white space in a good way and I
like to see a balance use of breaks to improve readability. That's my
take :)
Regards,
Andrew Eddie
Ed Stafford
>
> What I see a lot is when you have the brace on the one line, and then
> a block of code, devs put in a new line to provide readable space. In
> my opinion, why not just put the brace on the new line _shrug_. Eg:
>
> if (condition) {
>
> many
> lines
> of
> code
>
> }
I know this is the style I'm used to, so I'd have to vote for it.
if (condition)
{
echo
print
whatever
}
Gets really cluttered for me. Way back in the day, it's how I wrote
my blocks, but no longer.
Paladin
On Nov 2, 3:27 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> I'm agnostic towards the variable names. I'm happy to go either way.
> I honestly don't know which is better or worse.
in on this as well. The purpose here isn't to inflict anything upon
the devs, but to formalize something that can be enforced as we move
forward. If including something will discourage folks from
participating, I don't want to put it in, period, no matter how much I
personally might think it's the right thing to do.
Louis Landry
Louis Landry
Ed Stafford
> So, just to be clear... I think I made a pretty accurate copy of what is
> proposed here and threw it up on pastebin so that people can see it a little
> more "formally".
> http://joomla.pastebin.com/f3a03a548
> I'm as yet still unsure what I think the best use of
> package/subpackage/category is.
I'd think something along the lines of:
Joomla/Library/Filters
Joomla/Library/Base
Joomla/Component/Content
Joomla/Includes/DatabaseAccess
--
Ed Stafford
Paladin
On Nov 4, 11:23 am, Louis Landry <louis.lan...@joomla.org> wrote:
> As much as I love my tabs, I am starting to see the way of the spaces. That
> being said, I wonder what kind of impact that is going to have on file size?
might mean an extra 50-100 bytes per file. The "--tab-width=4" option
on phpcs pretty much allows them everywhere else, and I don't see a
real gain in replacing tabs with spaces as original line indents.
> I'm as yet still unsure what I think the best use of
> package/subpackage/category is.
appear to be a meaning for it in phpdoc that I've been able to notice
(unlike package/subpackage) and its existence seems only to spawn
confusion.
Looking more seriously over this, why is "Joomla" part of category/
package/subpackage considerations? Isn't *everything* here part of
that, and wouldn't 3PD's be using their own package/subpackage
arrangements? A level of a hierarchy with only one value isn't really
a level at all.
> The more I think about it the less I really like having the variable name in
> the @param tag and the @var tag. I really don't see how it really helps
> us with much of anything, and is really unnecessary in my opinion.
@params against the actual method. Without it, there is no way to tell
if the param descriptions are in the same order as the params
themselves, or if the params may have been changed without changing
the description.
For example, if a method takes two arguments, $fred and $george, and
the @param tags aren't accompanied by a name, we can only assume the
descriptions are in the same order as the arguments. Let's say they
are, but a later bit of maintenance results in adding a new param,
$florence, between $fred and $george. If the comments aren't updated,
phpdoc creates a new line for the third param, but also assumes
$george's description now belongs to $florence. If a variable name has
been assigned, phpdoc can still find the right description.
Further, let's say a later bit of maintenance drops $george from the
list. Now there are the same number of descriptions as params, but
they're wrong.
OTOH, let's assume names were included in the original setup. Now the
first maintenance pass keeps the descriptions associated with the
correct params, and includes a blank desc for $florence. After the
second pass, phpdoc retains the $george param and description, which
gives you an instant flag that something's wrong, because it's listing
a non-existing param, as opposed to no indication at all that a
description is wrong, as happens without names.
Now let's plug our codesniffer in the process. It can flag that a
param tag is missing, but will assume it's the $george one, instead of
the $florence one. It could also flag an excess one. This ameliorates
the problem, as a pass through codesniffer will pick up changes in
number of params, but will not pick up the fact one has changed it's
name. (Changing $george to $florence will not trigger anything from
either codesniffer or phpdoc, even though the change signals a change
in the purpose of the param.)
That's pretty much the case for including names for @param lines. If
that's not enough to make the point, we'll leave it out.
I don't think we were suggesting putting the name on @var lines.
There's a similar, but less forceful, argument that can be made for
it, but I'm not entirely convinced it's right.
> I would, however, lean towards making @since a required tag because I do
> find it useful when looking at documentation to know which versions of the
> software something became available for.
though.
Ian MacLennan
We're talking about them only in terms of the docblock, I think. Which
On Nov 4, 11:23 am, Louis Landry <louis.lan...@joomla.org> wrote:
> As much as I love my tabs, I am starting to see the way of the spaces. That
> being said, I wonder what kind of impact that is going to have on file size?
might mean an extra 50-100 bytes per file. The "--tab-width=4" option
on phpcs pretty much allows them everywhere else, and I don't see a
real gain in replacing tabs with spaces as original line indents.
Having one rule for doc blocks and one for code seems ugly to me. But whatever.
> I'm as yet still unsure what I think the best use ofI'm growing more convinced category doesn't belong here. There doesn't
> package/subpackage/category is.
appear to be a meaning for it in phpdoc that I've been able to notice
(unlike package/subpackage) and its existence seems only to spawn
confusion.
The @category tag is used to organize groups of packages together. This is directly applicable to the XML:DocBook/peardoc2 Converter, and can be used by other converters. Other Converters packaged with phpDocumentor ignore the category, but this may change in future versions. It is also possible to dynamically specify category using the -dc, --defaultcategoryname command-line switch.
@category might always be joomla (to differentiate from other stuff?). This might be useful in terms of differentiating between what is core and what is a third party lib (i.e. simplepie or other libraries).
Looking more seriously over this, why is "Joomla" part of category/
package/subpackage considerations? Isn't *everything* here part of
that, and wouldn't 3PD's be using their own package/subpackage
arrangements? A level of a hierarchy with only one value isn't really
a level at all.
Not everything is Joomla core - as mentioned above, we have third party libraries. See api.joomla.org for an example.
The documented usage here includes $paramname. For the reasons outlined, I would argue in favour of including. In addition, this would allow us to be consistent in cases where we use func_get_arg().
> I would, however, lean towards making @since a required tag because I doOK, filling that info in accurately might require some research,
> find it useful when looking at documentation to know which versions of the
> software something became available for.
though.
Ian
Andrew Eddie
Tabs are the current and past standard (has been since 2003).
Louis Landry
Wilco Jansen
There is a maybe less obvious reason for using the variable name in the @param markup. During development the interface of the method changes easy, and not everyone is keeping track at the docbook markups during the development stage. If you leave out the variable name you can mix up the docbook lines, because you never know to what variable the markup is referring, just an example.
/*
* @param string The sentence we want to search and replace
* @param array The keywords to look for
*/
function dosomething ($var1, $var2)
{
// here goes the logic
}
How can we determine that the first markup is referring to the first variable? The adjusted example shows how obvious it is (although they are accidentally listed in reversed order).
/*
* @param string $var2 The sentence we want to search and replace
* @param array $var1 The keywords to look for
*/
function dosomething ($var1, $var2)
{
// here goes the logic
}
This, and only this is the reason why you would insert variable names.
Regards, Wilco
Andrew Eddie
Docblock when they change the arguments list (figuratively, of
course). I think you are trying to mitigate something that is
inherently preventable and if the Docblock params are out of order,
then it's wrong. I don't think that's a good reason for having them.
The only thing I've seen is that PDT in eclipse does give you slightly
better context help if the variable names are there - but then I don't
use PDT. Even with that, I can't really see enough value added by
having them.
2009/11/5 Wilco Jansen <jansen...@gmail.com>:
Wilco Jansen
Andrew Eddie
Seriously, if you don't change the order of the params when you change
the argument list, the problem is with the developer.
Wilco Jansen
Andrew Eddie
Louis Landry
Paladin
On Nov 4, 5:46 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> I said figuratively :P
>
> Seriously, if you don't change the order of the params when you change
> the argument list, the problem is with the developer.
precisely that happening.
Sounds like the param name is a no-go. In any case, I've had my say on
this; I can't think of anything more to say that isn't just a
repetition of what I've said before.
Paladin
Does the "brace on line by itself" style hold not only for if, but for
the other control structures (do, while, for) as well?
Oh, and the hybrid idea is going to be hard to implement. Codesniffer
wants a single signature for a control signature. If it's going to
vary with length of coding block below it, I'm going to have (re)write
a chunk of the sniffer code itself, AFAICT.
Andrew Eddie
>
> One other thought:
>
> Does the "brace on line by itself" style hold not only for if, but for
> the other control structures (do, while, for) as well?
Yes, it does. switch as well.
Niels Braczek
> Does the "brace on line by itself" style hold not only for if, but for
> the other control structures (do, while, for) as well?
Yes, it does.
> Oh, and the hybrid idea is going to be hard to implement. Codesniffer
> wants a single signature for a control signature. If it's going to
> vary with length of coding block below it, I'm going to have (re)write
> a chunk of the sniffer code itself, AFAICT.
With only very few exceptions, the PEAR style is used in the core (and
evrywhere else). I see no benefit in changing that. The "brace on line
by itself" style is C, not PHP.
Regards,
Niels
--
| http://www.kolleg.de · Das Portal der Kollegs in Deutschland |
| http://www.bsds.de · BSDS Braczek Software- und DatenSysteme |
| Webdesign · Webhosting · e-Commerce · Joomla! Content Management |
------------------------------------------------------------------
Paladin
On Nov 5, 3:37 pm, Andrew Eddie <mambob...@gmail.com> wrote:
> 2009/11/6 Paladin <arlen.wal...@gmail.com>:
> Yes, it does. switch as well.
Sniffer). Should get the if's and the @param;s right as well as most
other control structures. The code for handling no varName in the
param is a bit fugly and I'll rework it after my understanding of the
code improves. The internals of phpcs want varName so I had to deceive
it to get it to do what I wanted. Long Term best approach is probably
creating some new classes extending its existing classes so I can
modify its internal parsers instead of hooking on to the outside of it
through the sniffers, but that's more than I care to tackle at the
moment; I don't understand it well enough to go mucking about in its
internals, yet.
BTW, right now the sniffer also requires a break for every case of a
switch.
Paladin
On Nov 5, 4:15 pm, Niels Braczek <nbrac...@bsds.de> wrote:
> With only very few exceptions, the PEAR style is used in the core (and
> evrywhere else). I see no benefit in changing that. The "brace on line
> by itself" style is C, not PHP.
into PEAR style, the only way I can confirm the above statement from
the code is if "with only very few exceptions" can somehow be bent
into meaning the same thing as "virtually every single time an else
clause occurs in an if."
An if without an else is generally, though not always, found in the
traditional PEAR style. An if *with* an else is seldom if ever found
in the PEAR style. Seems to be about evenly split between "}\n else \n
{", "} else \n {" and "} \n else {" with "} else {" (the PEAR style)
trailing far behind any of the other three.