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. [0] http://www.php-fig.org/psr/psr-1/#2-3-side-effects

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.

[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

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 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.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

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.