23 Aug
2015
23 Aug
'15
3:58 p.m.
Hi,
phpMyAdmin's ruleset is based on PEAR standards. One of this standard
(PEAR_Sniffs_NamingConventions_ValidVariableNameSniff) is to name class'
attributes / methods with a leading underscore when the element is
protected / private.
This rule is quite useful because it helps to see very quickly if an
element is public or not. But
http://www.php-fig.org/psr/psr-2/#4-2-properties asks not to use this
leading underscore.
For attributes, I'm not sure this is a big deal because almost all the
attributes shouldn't be visible and accessible only by getters / setters.
But for methods, there is nothing to know the visibility of a method.
However actual IDE help to see this.
Do you think that we should follow PSR2? Only for attributes maybe?
Should we consider to base our ruleset on another standard closest to PSR
rules?
Thanks for your feedback,
H.
24 Aug
24 Aug
4:01 a.m.
New subject: PHPCS: leading underscore on protected / private attributes / methods
Hi
Dne Sun, 23 Aug 2015 18:58:19 +0000
Hugues Peccatte <hugues.peccatte(a)gmail.com> napsal(a):
phpMyAdmin's ruleset is based on PEAR standards.
One of this standard
(PEAR_Sniffs_NamingConventions_ValidVariableNameSniff) is to name class'
attributes / methods with a leading underscore when the element is
protected / private.
This rule is quite useful because it helps to see very quickly if an
element is public or not. But
http://www.php-fig.org/psr/psr-2/#4-2-properties asks not to use this
leading underscore.
For attributes, I'm not sure this is a big deal because almost all the
attributes shouldn't be visible and accessible only by getters / setters.
But for methods, there is nothing to know the visibility of a method.
However actual IDE help to see this.
Do you think that we should follow PSR2? Only for attributes maybe?
Should we consider to base our ruleset on another standard closest to PSR
rules?
I think leaning towards PSR-1/2 is good idea.
--
Michal Čihař | http://cihar.com | http://blog.cihar.com
25 Aug
25 Aug
7:05 a.m.
New subject: PHPCS: leading underscore on protected / private attributes / methods
On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte <hugues.peccatte(a)gmail.com
wrote:
Hi,
phpMyAdmin's ruleset is based on PEAR standards. One of this standard
(PEAR_Sniffs_NamingConventions_ValidVariableNameSniff) is to name class'
attributes / methods with a leading underscore when the element is
protected / private.
This rule is quite useful because it helps to see very quickly if an
element is public or not. But
http://www.php-fig.org/psr/psr-2/#4-2-properties asks not to use this
leading underscore.
For attributes, I'm not sure this is a big deal because almost all the
attributes shouldn't be visible and accessible only by getters / setters.
But for methods, there is nothing to know the visibility of a method.
However actual IDE help to see this.
Do you think that we should follow PSR2? Only for attributes maybe?
Should we consider to base our ruleset on another standard closest to PSR
rules?
Hi,
I agree to follow PSR-2 no underscore recommendation for attributes and
going forward we may lean more towards PSR, specifically about achieving
codebase wide autoloading of classes(PSR-4).
Also, I think https://github.com/phpmyadmin/phpmyadmin/pull/11365 needs to
be rebased.
--
Regards
Atul Pratap Singh
10:40 a.m.
New subject: PHPCS: leading underscore on protected / private attributes / methods
Le mar. 25 août 2015 à 12:06, Atul Pratap Singh <atulpratapsingh05(a)gmail.com>
a écrit :
On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte
<
hugues.peccatte(a)gmail.com> wrote:
Hi,
I won't rebase the branch but remove it.
I'll see the modifications I can do to stick to PSR 0 to 2 rules.
H.
Hi,
phpMyAdmin's ruleset is based on PEAR standards. One of this standard
(PEAR_Sniffs_NamingConventions_ValidVariableNameSniff) is to name class'
attributes / methods with a leading underscore when the element is
protected / private.
This rule is quite useful because it helps to see very quickly if an
element is public or not. But
http://www.php-fig.org/psr/psr-2/#4-2-properties asks not to use this
leading underscore.
For attributes, I'm not sure this is a big deal because almost all the
attributes shouldn't be visible and accessible only by getters / setters.
But for methods, there is nothing to know the visibility of a method.
However actual IDE help to see this.
Do you think that we should follow PSR2? Only for attributes maybe?
Should we consider to base our ruleset on another standard closest to PSR
rules?
Hi,
I agree to follow PSR-2 no underscore recommendation for attributes and
going forward we may lean more towards PSR, specifically about achieving
codebase wide autoloading of classes(PSR-4).
Also, I think https://github.com/phpmyadmin/phpmyadmin/pull/11365 needs
to be rebased.
--
Regards
Atul Pratap Singh
26 Aug
26 Aug
6:34 a.m.
New subject: PHPCS: leading underscore on protected / private attributes / methods
Le mar. 25 août 2015 à 15:40, Hugues Peccatte <hugues.peccatte(a)gmail.com> a
écrit :
Le mar. 25 août 2015 à 12:06, Atul Pratap Singh <
atulpratapsingh05(a)gmail.com> a écrit :
Hi,
Some days ago, we spoke about this code in all files:
if (! defined('PHPMYADMIN')) {
exit;
}
In PSR, one of the rules is the "side effects" [0]. This rule says not to
have class/functions/etc declaration and execution in the same file. And
the code above is considered as execution. So here I don't want to restart
the discussion, but we may have to change this if we really want to stick
(not sure about this english word…) to PSR rules.
H.
[0] http://www.php-fig.org/psr/psr-1/#2-3-side-effects
On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte
<
hugues.peccatte(a)gmail.com> wrote:
Hi,
I won't rebase the branch but remove it.
I'll see the modifications I can do to stick to PSR 0 to 2 rules.
H.
Hi,
phpMyAdmin's ruleset is based on PEAR standards. One of this standard
(PEAR_Sniffs_NamingConventions_ValidVariableNameSniff) is to name class'
attributes / methods with a leading underscore when the element is
protected / private.
This rule is quite useful because it helps to see very quickly if an
element is public or not. But
http://www.php-fig.org/psr/psr-2/#4-2-properties asks not to use this
leading underscore.
For attributes, I'm not sure this is a big deal because almost all the
attributes shouldn't be visible and accessible only by getters / setters.
But for methods, there is nothing to know the visibility of a method.
However actual IDE help to see this.
Do you think that we should follow PSR2? Only for attributes maybe?
Should we consider to base our ruleset on another standard closest to
PSR rules?
Hi,
I agree to follow PSR-2 no underscore recommendation for attributes and
going forward we may lean more towards PSR, specifically about achieving
codebase wide autoloading of classes(PSR-4).
Also, I think https://github.com/phpmyadmin/phpmyadmin/pull/11365 needs
to be rebased.
--
Regards
Atul Pratap Singh
8:49 a.m.
New subject: PHPCS: leading underscore on protected / private attributes / methods
Le 2015-08-26 05:34, Hugues Peccatte a écrit :
Le mar. 25 août 2015 à 15:40, Hugues Peccatte
<hugues.peccatte(a)gmail.com
<mailto:hugues.peccatte@gmail.com>> a écrit :
Le mar. 25 août 2015 à 12:06, Atul Pratap Singh
<atulpratapsingh05(a)gmail.com <mailto:atulpratapsingh05@gmail.com>> a
écrit :
On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte
<hugues.peccatte(a)gmail.com <mailto:hugues.peccatte@gmail.com>>
wrote:
Hi,
phpMyAdmin's ruleset is based on PEAR standards. One of this
standard
(PEAR_Sniffs_NamingConventions_ValidVariableNameSniff) is to
name class' attributes / methods with a leading underscore
when the element is protected / private.
This rule is quite useful because it helps to see very
quickly if an element is public or not.
But http://www.php-fig.org/psr/psr-2/#4-2-properties asks
not to use this leading underscore.
For attributes, I'm not sure this is a big deal because
almost all the attributes shouldn't be visible and
accessible only by getters / setters. But for methods, there
is nothing to know the visibility of a method. However
actual IDE help to see this.
Do you think that we should follow PSR2? Only for attributes
maybe?
Should we consider to base our ruleset on another standard
closest to PSR rules?
Hi,
I agree to follow PSR-2 no underscore recommendation for
attributes and going forward we may lean more towards PSR,
specifically about achieving codebase wide autoloading of
classes(PSR-4).
Also, I
think https://github.com/phpmyadmin/phpmyadmin/pull/11365 needs
to be rebased.
--
Regards
Atul Pratap Singh
Hi,
I won't rebase the branch but remove it.
I'll see the modifications I can do to stick to PSR 0 to 2 rules.
H.
Hi,
Some days ago, we spoke about this code in all files:
if (! defined('PHPMYADMIN')) {
exit;
}
In PSR, one of the rules is the "side effects" [0]. This rule says not
to have class/functions/etc declaration and execution in the same file.
And the code above is considered as execution. So here I don't want to
restart the discussion, but we may have to change this if we really want
to stick (not sure about this english word…) to PSR rules.
H.
[0] http://www.php-fig.org/psr/psr-1/#2-3-side-effects
This constant verification can safely be removed if there is no other
"execution" code in the file.
--
Marc Delisle | phpMyAdmin
5:05 p.m.
New subject: PHPCS: leading underscore on protected / private attributes / methods
Le mer. 26 août 2015 à 14:10, Marc Delisle <marc(a)infomarc.info> a écrit :
Le 2015-08-26 05:34, Hugues Peccatte a écrit :
Hi,
Has anyone an idea about the origin of this error please?
https://travis-ci.org/phpmyadmin/phpmyadmin/jobs/77383289
I don't see anything special in my modifications that can lead to this
error…
Thanks,
H.
Le mar. 25 août 2015 à 15:40, Hugues Peccatte
<hugues.peccatte(a)gmail.com
<mailto:hugues.peccatte@gmail.com>> a écrit :
Le mar. 25 août 2015 à 12:06, Atul Pratap Singh
<atulpratapsingh05(a)gmail.com <mailto:atulpratapsingh05@gmail.com>> a
écrit :
On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte
<hugues.peccatte(a)gmail.com <mailto:hugues.peccatte@gmail.com>>
wrote:
Hi,
phpMyAdmin's ruleset is based on PEAR standards. One of this
standard
(PEAR_Sniffs_NamingConventions_ValidVariableNameSniff) is to
name class' attributes / methods with a leading underscore
when the element is protected / private.
This rule is quite useful because it helps to see very
quickly if an element is public or not.
But http://www.php-fig.org/psr/psr-2/#4-2-properties asks
not to use this leading underscore.
For attributes, I'm not sure this is a big deal because
almost all the attributes shouldn't be visible and
accessible only by getters / setters. But for methods, there
is nothing to know the visibility of a method. However
actual IDE help to see this.
Do you think that we should follow PSR2? Only for attributes
maybe?
Should we consider to base our ruleset on another standard
closest to PSR rules?
Hi,
I agree to follow PSR-2 no underscore recommendation for
attributes and going forward we may lean more towards PSR,
specifically about achieving codebase wide autoloading of
classes(PSR-4).
Also, I
think https://github.com/phpmyadmin/phpmyadmin/pull/11365 needs
to be rebased.
--
Regards
Atul Pratap Singh
Hi,
I won't rebase the branch but remove it.
I'll see the modifications I can do to stick to PSR 0 to 2 rules.
H.
Hi,
Some days ago, we spoke about this code in all files:
if (! defined('PHPMYADMIN')) {
exit;
}
In PSR, one of the rules is the "side effects" [0]. This rule says not
to have class/functions/etc declaration and execution in the same file.
And the code above is considered as execution. So here I don't want to
restart the discussion, but we may have to change this if we really want
to stick (not sure about this english word…) to PSR rules.
H.
[0] http://www.php-fig.org/psr/psr-1/#2-3-side-effects
This constant verification can safely be removed if there is no other
"execution" code in the file.
--
Marc Delisle | phpMyAdmin
27 Aug
27 Aug
2:09 a.m.
New subject: PHPCS: leading underscore on protected / private attributes / methods
Dne Wed, 26 Aug 2015 20:05:58 +0000
Hugues Peccatte <hugues.peccatte(a)gmail.com> napsal(a):
Le mer. 26 août 2015 à 14:10, Marc Delisle
<marc(a)infomarc.info> a écrit :
Looks like problem with compiling runkit extension... I've changed the
code to stick with particular runkit revision which compiles fine.
--
Michal Čihař | http://cihar.com | http://phpmyadmin.net
Le 2015-08-26 05:34, Hugues Peccatte a écrit :
Hi,
Has anyone an idea about the origin of this error please?
https://travis-ci.org/phpmyadmin/phpmyadmin/jobs/77383289
I don't see anything special in my modifications that can lead to this
error… Le mar. 25 août 2015 à 15:40, Hugues Peccatte
<hugues.peccatte(a)gmail.com
<mailto:hugues.peccatte@gmail.com>> a écrit :
Le mar. 25 août 2015 à 12:06, Atul Pratap Singh
<atulpratapsingh05(a)gmail.com <mailto:atulpratapsingh05@gmail.com>> a
écrit :
On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte
<hugues.peccatte(a)gmail.com <mailto:hugues.peccatte@gmail.com>>
wrote:
Hi,
phpMyAdmin's ruleset is based on PEAR standards. One of this
standard
(PEAR_Sniffs_NamingConventions_ValidVariableNameSniff) is to
name class' attributes / methods with a leading underscore
when the element is protected / private.
This rule is quite useful because it helps to see very
quickly if an element is public or not.
But http://www.php-fig.org/psr/psr-2/#4-2-properties asks
not to use this leading underscore.
For attributes, I'm not sure this is a big deal because
almost all the attributes shouldn't be visible and
accessible only by getters / setters. But for methods, there
is nothing to know the visibility of a method. However
actual IDE help to see this.
Do you think that we should follow PSR2? Only for attributes
maybe?
Should we consider to base our ruleset on another standard
closest to PSR rules?
Hi,
I agree to follow PSR-2 no underscore recommendation for
attributes and going forward we may lean more towards PSR,
specifically about achieving codebase wide autoloading of
classes(PSR-4).
Also, I
think https://github.com/phpmyadmin/phpmyadmin/pull/11365 needs
to be rebased.
--
Regards
Atul Pratap Singh
Hi,
I won't rebase the branch but remove it.
I'll see the modifications I can do to stick to PSR 0 to 2 rules.
H.
Hi,
Some days ago, we spoke about this code in all files:
if (! defined('PHPMYADMIN')) {
exit;
}
In PSR, one of the rules is the "side effects" [0]. This rule says not
to have class/functions/etc declaration and execution in the same file.
And the code above is considered as execution. So here I don't want to
restart the discussion, but we may have to change this if we really want
to stick (not sure about this english word…) to PSR rules.
H.
[0] http://www.php-fig.org/psr/psr-1/#2-3-side-effects
This constant verification can safely be removed if there is no other
"execution" code in the file.
--
Marc Delisle | phpMyAdmin
11:13 a.m.
New subject: PHPCS: leading underscore on protected / private attributes / methods
Le jeu. 27 août 2015 à 07:10, Michal Čihař <michal(a)cihar.com> a écrit :
Dne Wed, 26 Aug 2015 20:05:58 +0000
Hugues Peccatte <hugues.peccatte(a)gmail.com> napsal(a):
Hi,
Has anyone an idea about the origin of this error please?
https://travis-ci.org/phpmyadmin/phpmyadmin/jobs/77383289
I don't see anything special in my modifications that can lead to this
error…
Looks like problem with compiling runkit extension... I've changed the
code to stick with particular runkit revision which compiles fine.
--
Michal Čihař | http://cihar.com | http://phpmyadmin.net
Thanks a not Michal, It seems to work now!
H.
Le mer. 26 août 2015 à 14:10, Marc Delisle
<marc(a)infomarc.info> a écrit
:
> Le 2015-08-26 05:34, Hugues Peccatte a écrit :
> > Le mar. 25 août 2015 à 15:40, Hugues Peccatte <
hugues.peccatte(a)gmail.com
> >
<mailto:hugues.peccatte@gmail.com>> a écrit :
> >
> > Le mar. 25 août 2015 à 12:06, Atul Pratap Singh
> > <atulpratapsingh05(a)gmail.com
<mailto:atulpratapsingh05@gmail.com>>
a
> > écrit :
> >
> > On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte
> > <hugues.peccatte(a)gmail.com <mailto:hugues.peccatte@gmail.com
>
> > wrote:
> >
> > Hi,
> >
> > phpMyAdmin's ruleset is based on PEAR standards. One of
this
> > standard
> > (PEAR_Sniffs_NamingConventions_ValidVariableNameSniff)
is
to
> > name class' attributes
/ methods with a leading
underscore
> > when the element is
protected / private.
> > This rule is quite useful because it helps to see very
> > quickly if an element is public or not.
> > But http://www.php-fig.org/psr/psr-2/#4-2-properties
asks
> > not to use this leading
underscore.
> > For attributes, I'm not sure this is a big deal because
> > almost all the attributes shouldn't be visible and
> > accessible only by getters / setters. But for methods,
there
> > is nothing to know the
visibility of a method. However
> > actual IDE help to see this.
> >
> > Do you think that we should follow PSR2? Only for
attributes
> > maybe?
> > Should we consider to base our ruleset on another
standard
> > closest to PSR rules?
> >
> > Hi,
> >
> > I agree to follow PSR-2 no underscore recommendation for
> > attributes and going forward we may lean more towards PSR,
> > specifically about achieving codebase wide autoloading of
> > classes(PSR-4).
> >
> > Also, I
> > think https://github.com/phpmyadmin/phpmyadmin/pull/11365
needs
> > to be rebased.
> >
> >
> > --
> > Regards
> >
> > Atul Pratap Singh
> >
> >
> > Hi,
> >
> > I won't rebase the branch but remove it.
> > I'll see the modifications I can do to stick to PSR 0 to 2 rules.
> >
> > H.
> >
> >
> > Hi,
> >
> > Some days ago, we spoke about this code in all files:
> > if (! defined('PHPMYADMIN')) {
> > exit;
> > }
> >
> > In PSR, one of the rules is the "side effects" [0]. This rule says
not
> > to have class/functions/etc declaration
and execution in the same
file.
> > And the code above is considered as
execution. So here I don't want
to
> > restart the discussion, but we may have
to change this if we really
want
to stick (not sure about this english word…) to PSR
rules.
H.
[0] http://www.php-fig.org/psr/psr-1/#2-3-side-effects
This constant verification can safely be removed if there is no other
"execution" code in the file.
--
Marc Delisle | phpMyAdmin
3300
days inactive
3304
days old
8 comments
4 participants
participants (4)
-
Atul Pratap Singh -
Hugues Peccatte -
Marc Delisle -
Michal Čihař