[phpMyAdmin Developers] PHPCS: leading underscore on protected / private attributes / methods

[Hugues Peccatte]

Le mer. 26 août 2015 à 14:10, Marc Delisle <marc at 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 at gmail.com
> > <mailto:hugues.peccatte at gmail.com>> a écrit :
> >
> >     Le mar. 25 août 2015 à 12:06, Atul Pratap Singh
> >     <atulpratapsingh05 at gmail.com <mailto:atulpratapsingh05 at gmail.com>> a
> >     écrit :
> >
> >         On Mon, Aug 24, 2015 at 12:28 AM, Hugues Peccatte
> >         <hugues.peccatte at gmail.com <mailto:hugues.peccatte at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.phpmyadmin.net/pipermail/developers/attachments/20150826/1afc4998/attachment.html>