FAQ
Edit report at http://pear.php.net/bugs/bug.php?id=18303&edit=1

ID: 18303
Updated by: gsherwood@squiz.net
Reported By: nitro2k01 at gmail dot com
Summary: Don't issue a warning for some uses of numbers in
variables
-Status: Open
+Status: Bogus
Type: Bug
Package: PHP_CodeSniffer
Operating System: n/a
Package Version: 1.2.2
PHP Version: 5.3.5
-Assigned To:
+Assigned To: squiz
Roadmap Versions:
New Comment:

-Status: Open
+Status: Bogus
-Assigned To:
+Assigned To: squiz
The first thing to note is that whoever reported the issue was obviously
using the Zend standard in PHP_CodeSniffer, or their own custom standard
that includes the sniff from within the Zend standard.

If they are using the Zend standard:
The Zend standard is *not* a complete coding standard. It is just a
collection of sniffs that were contributed to phpcs and are to be used
in custom standards. The default phpcs standard is PEAR, which doesn't
contain this check. The other complete standard that is included is
Squiz, which also doesn't contain this check. I suggest using a complete
standard (either PEAR or Squiz) or getting hold of a standard written
specifically for the code they are writing (like a Zend Framework one).

If they are using a custom standard:
Remove the sniff from the custom standard if you don't like it. Or you
could write your won ruleset.xml file (see the docs) to mute the error
message if you prefer.

In general:
PHPCS is a tool for checking code against standards. It is not a single
standard. It checks is whatever way you tell it to check. The result is
that it should be flexible enough for you to configure it to report the
sort of errors you want. If a particular standard seems too strict, you
need to ask the standard author to see what their intention was. I can
comment on the Squiz standard (I wrote it) but not any others as I just
implement them in code rather than maintain the writen standard.

I hope that is enough info to go back with. If not, you can also contact
me through the PEAR website by clicking my name and then looking for the
email link.


Previous Comments:
------------------------------------------------------------------------

[2011-02-23 21:12:53] nitro2k01

Description:
------------
This might come across as odd as I've not actually used PHP_CodeSniffer
myself, but am reporting this because of a question that was asked in a
forum. Please forgive if I'm making any bad assumptions.

The issue is that when validating code, there's apparently a warning for
variables containing numbers. ("Variable "base64" contains numbers but
this is discouraged") I'm assuming this warning is issued because it's
semantically wrong to call variables something like $var1 $var2 $var3
where e.g. an array is more appropriate.

However, in the question being asked the warning was issued for a
variable called $base64. In that case, it's not semantically wrong to
call the variable that, as $base64 is not the 64th variable in a series,
but basne64-encoded data. The same could be true for names containing
md5, sha1 or other names of things containing numbers. My suggestion is
to silence that warning if a number in a variable is part of a known
name for something.

------------------------------------------------------------------------

Search Discussions

  • Nitro2k01 at Feb 24, 2011 at 4:44 am
    Edit report at http://pear.php.net/bugs/bug.php?id=18303&edit=1

    ID: 18303
    Updated by: nitro2k01@gmail.com
    Reported By: nitro2k01 at gmail dot com
    Summary: Don't issue a warning for some uses of numbers in
    variables
    Status: Bogus
    Type: Bug
    Package: PHP_CodeSniffer
    Operating System: n/a
    Package Version: 1.2.2
    PHP Version: 5.3.5
    Assigned To: squiz
    Roadmap Versions:
    New Comment:

    As your deduction tells you, this user was testing against Zend. Because
    of the circumstances, I adviced the user to just ignore that particular
    warning. However, I'm also contacting you to suggest the idea of
    silencing that warning under certain circumstances, if that's even
    technically possible. It's simply just a suggestion.

    If the current behavior is "by design" - and you should be able to judge
    better than me - then feel free to close this ticket.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-02-24 04:42:38] squiz

    -Status: Open
    +Status: Bogus
    -Assigned To:
    +Assigned To: squiz
    The first thing to note is that whoever reported the issue was obviously
    using the Zend standard in PHP_CodeSniffer, or their own custom standard
    that includes the sniff from within the Zend standard.

    If they are using the Zend standard:
    The Zend standard is *not* a complete coding standard. It is just a
    collection of sniffs that were contributed to phpcs and are to be used
    in custom standards. The default phpcs standard is PEAR, which doesn't
    contain this check. The other complete standard that is included is
    Squiz, which also doesn't contain this check. I suggest using a complete
    standard (either PEAR or Squiz) or getting hold of a standard written
    specifically for the code they are writing (like a Zend Framework one).

    If they are using a custom standard:
    Remove the sniff from the custom standard if you don't like it. Or you
    could write your won ruleset.xml file (see the docs) to mute the error
    message if you prefer.

    In general:
    PHPCS is a tool for checking code against standards. It is not a single
    standard. It checks is whatever way you tell it to check. The result is
    that it should be flexible enough for you to configure it to report the
    sort of errors you want. If a particular standard seems too strict, you
    need to ask the standard author to see what their intention was. I can
    comment on the Squiz standard (I wrote it) but not any others as I just
    implement them in code rather than maintain the writen standard.

    I hope that is enough info to go back with. If not, you can also contact
    me through the PEAR website by clicking my name and then looking for the
    email link.

    ------------------------------------------------------------------------

    [2011-02-23 21:12:53] nitro2k01

    Description:
    ------------
    This might come across as odd as I've not actually used PHP_CodeSniffer
    myself, but am reporting this because of a question that was asked in a
    forum. Please forgive if I'm making any bad assumptions.

    The issue is that when validating code, there's apparently a warning for
    variables containing numbers. ("Variable "base64" contains numbers but
    this is discouraged") I'm assuming this warning is issued because it's
    semantically wrong to call variables something like $var1 $var2 $var3
    where e.g. an array is more appropriate.

    However, in the question being asked the warning was issued for a
    variable called $base64. In that case, it's not semantically wrong to
    call the variable that, as $base64 is not the 64th variable in a series,
    but basne64-encoded data. The same could be true for names containing
    md5, sha1 or other names of things containing numbers. My suggestion is
    to silence that warning if a number in a variable is part of a known
    name for something.

    ------------------------------------------------------------------------
  • Gsherwood at Feb 24, 2011 at 4:47 am
    Edit report at http://pear.php.net/bugs/bug.php?id=18303&edit=1

    ID: 18303
    Updated by: gsherwood@squiz.net
    Reported By: nitro2k01 at gmail dot com
    Summary: Don't issue a warning for some uses of numbers in
    variables
    Status: Bogus
    Type: Bug
    Package: PHP_CodeSniffer
    Operating System: n/a
    Package Version: 1.2.2
    PHP Version: 5.3.5
    Assigned To: squiz
    Roadmap Versions:
    New Comment:

    It's certainly by design for that sniff and I don't see how it is
    technically possible to determine if numbers should be in a variable,
    hence my suggestions for how to either use one of the real standards or
    to create your own.

    Note that one of my suggestions (the ruleset.xml) is how you can
    actually mute the error as well. There are plenty of options and
    settings to build the standard you want. I think this person should be
    encouraged to explore them all.


    Previous Comments:
    ------------------------------------------------------------------------

    [2011-02-24 05:47:13] nitro2k01

    As your deduction tells you, this user was testing against Zend. Because
    of the circumstances, I adviced the user to just ignore that particular
    warning. However, I'm also contacting you to suggest the idea of
    silencing that warning under certain circumstances, if that's even
    technically possible. It's simply just a suggestion.

    If the current behavior is "by design" - and you should be able to judge
    better than me - then feel free to close this ticket.

    ------------------------------------------------------------------------

    [2011-02-24 04:42:38] squiz

    -Status: Open
    +Status: Bogus
    -Assigned To:
    +Assigned To: squiz
    The first thing to note is that whoever reported the issue was obviously
    using the Zend standard in PHP_CodeSniffer, or their own custom standard
    that includes the sniff from within the Zend standard.

    If they are using the Zend standard:
    The Zend standard is *not* a complete coding standard. It is just a
    collection of sniffs that were contributed to phpcs and are to be used
    in custom standards. The default phpcs standard is PEAR, which doesn't
    contain this check. The other complete standard that is included is
    Squiz, which also doesn't contain this check. I suggest using a complete
    standard (either PEAR or Squiz) or getting hold of a standard written
    specifically for the code they are writing (like a Zend Framework one).

    If they are using a custom standard:
    Remove the sniff from the custom standard if you don't like it. Or you
    could write your won ruleset.xml file (see the docs) to mute the error
    message if you prefer.

    In general:
    PHPCS is a tool for checking code against standards. It is not a single
    standard. It checks is whatever way you tell it to check. The result is
    that it should be flexible enough for you to configure it to report the
    sort of errors you want. If a particular standard seems too strict, you
    need to ask the standard author to see what their intention was. I can
    comment on the Squiz standard (I wrote it) but not any others as I just
    implement them in code rather than maintain the writen standard.

    I hope that is enough info to go back with. If not, you can also contact
    me through the PEAR website by clicking my name and then looking for the
    email link.

    ------------------------------------------------------------------------

    [2011-02-23 21:12:53] nitro2k01

    Description:
    ------------
    This might come across as odd as I've not actually used PHP_CodeSniffer
    myself, but am reporting this because of a question that was asked in a
    forum. Please forgive if I'm making any bad assumptions.

    The issue is that when validating code, there's apparently a warning for
    variables containing numbers. ("Variable "base64" contains numbers but
    this is discouraged") I'm assuming this warning is issued because it's
    semantically wrong to call variables something like $var1 $var2 $var3
    where e.g. an array is more appropriate.

    However, in the question being asked the warning was issued for a
    variable called $base64. In that case, it's not semantically wrong to
    call the variable that, as $base64 is not the 64th variable in a series,
    but basne64-encoded data. The same could be true for names containing
    md5, sha1 or other names of things containing numbers. My suggestion is
    to silence that warning if a number in a variable is part of a known
    name for something.

    ------------------------------------------------------------------------

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppear-bugs @
categoriesphp
postedFeb 24, '11 at 3:39a
activeFeb 24, '11 at 4:47a
posts3
users2
websitepear.php.net

2 users in discussion

Gsherwood: 2 posts Nitro2k01: 1 post

People

Translate

site design / logo © 2022 Grokbase