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.
Hi
Dne Sun, 23 Aug 2015 18:58:19 +0000 Hugues Peccatte hugues.peccatte@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.
On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte <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
Le mar. 25 août 2015 à 12:06, Atul Pratap Singh atulpratapsingh05@gmail.com a écrit :
On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte < 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.
Le mar. 25 août 2015 à 15:40, Hugues Peccatte hugues.peccatte@gmail.com a écrit :
Le mar. 25 août 2015 à 12:06, Atul Pratap Singh < atulpratapsingh05@gmail.com> a écrit :
On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte < 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.
Le 2015-08-26 05:34, Hugues Peccatte a écrit :
Le mar. 25 août 2015 à 15:40, Hugues Peccatte <hugues.peccatte@gmail.com mailto:hugues.peccatte@gmail.com> a écrit :
Le mar. 25 août 2015 à 12:06, Atul Pratap Singh <atulpratapsingh05@gmail.com <mailto:atulpratapsingh05@gmail.com>> a écrit : On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte <hugues.peccatte@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.
This constant verification can safely be removed if there is no other "execution" code in the file.
Le mer. 26 août 2015 à 14:10, Marc Delisle marc@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@gmail.com mailto:hugues.peccatte@gmail.com> a écrit :
Le mar. 25 août 2015 à 12:06, Atul Pratap Singh <atulpratapsingh05@gmail.com <mailto:atulpratapsingh05@gmail.com>> a écrit : On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte <hugues.peccatte@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.
This constant verification can safely be removed if there is no other "execution" code in the file.
-- Marc Delisle | phpMyAdmin
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.
Dne Wed, 26 Aug 2015 20:05:58 +0000 Hugues Peccatte hugues.peccatte@gmail.com napsal(a):
Le mer. 26 août 2015 à 14:10, Marc Delisle marc@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@gmail.com mailto:hugues.peccatte@gmail.com> a écrit :
Le mar. 25 août 2015 à 12:06, Atul Pratap Singh <atulpratapsingh05@gmail.com <mailto:atulpratapsingh05@gmail.com>> a écrit : On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte <hugues.peccatte@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.
This constant verification can safely be removed if there is no other "execution" code in the file.
-- Marc Delisle | phpMyAdmin
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.
Le jeu. 27 août 2015 à 07:10, Michal Čihař michal@cihar.com a écrit :
Dne Wed, 26 Aug 2015 20:05:58 +0000 Hugues Peccatte hugues.peccatte@gmail.com napsal(a):
Le mer. 26 août 2015 à 14:10, Marc Delisle marc@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@gmail.com
mailto:hugues.peccatte@gmail.com> a écrit :
Le mar. 25 août 2015 à 12:06, Atul Pratap Singh <atulpratapsingh05@gmail.com <mailto:atulpratapsingh05@gmail.com>>a
écrit : On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte <hugues.peccatte@gmail.com <mailto:hugues.peccatte@gmail.comwrote: Hi, phpMyAdmin's ruleset is based on PEAR standards. One ofthis
standard (PEAR_Sniffs_NamingConventions_ValidVariableNameSniff)is to
name class' attributes / methods with a leadingunderscore
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-propertiesasks
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 forattributes
maybe? Should we consider to base our ruleset on anotherstandard
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/11365needs
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.
This constant verification can safely be removed if there is no other "execution" code in the file.
-- Marc Delisle | phpMyAdmin
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.
-
Atul Pratap Singh -
Hugues Peccatte -
Marc Delisle -
Michal Čihař