Difference between 2 installs of PHPCS about php_codesniffer HOT 28 CLOSED

Is it possible that different versions of PHP are being used?

One way to compare the installs is also to use the -vv command line argument. This will show how the custom ruleset was included and how each file was tokenized, to confirm that PHPCS is seeing the file in the same way. If you use -vvv it will also show each sniff that is being processed on each token. It might be a bit much to read through manually, but doing a diff on the output might uncover a problem.

from php_codesniffer.

PHP version on the Mac:

PHP 5.4.19 (cli) (built: Sep 18 2013 14:26:26) Copyright (c) 1997-2013 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2013 Zend Technologies with XCache v2.0.1, Copyright (c) 2005-2012, by mOo

And on the server:

PHP 5.4.31 (cli) (built: Jul 24 2014 09:24:28) Copyright (c) 1997-2014 The PHP Group Zend Engine v2.4.0, Copyright (c) 1998-2014 Zend Technologies

from php_codesniffer.

The out put using -vv on the mac states:

[4309 tokens in 534 lines]... DONE in 1 second (0 errors, 0 warnings)

And on the server:

[4309 tokens in 534 lines]... DONE in < 1 second (18 errors, 0 warnings)

from php_codesniffer.

If you just use the basic -v option, the output will include something like:

$ phpcs temp.php -v
Registering sniffs in the PEAR standard... DONE (26 sniffs registered)

Do you see the same number of sniffs registered between installs? If so, the only thing left is to compare the output of -vvv and check that it is the same, unless the custom coding standard happens to have unit tests you can run to compare results.

from php_codesniffer.

AH HA!! So, I piped the output into txt files and diff'd them and it appears that the local install is not loading any additional Sniffs...
The lines after:

Adding sniff files from "/.../CakePHP/Sniffs/" directory

On the local install are all blank...? On the server there's a whole bunch Sniffs included. So while I can run PHPCS from comandline on the mac, and use the standard it doesn't find the Standard's included Sniffs!

Any suggestions?

from php_codesniffer.

Stupid question, but I have to ask: are their sub-directories and files inside the CakePHP/Sniffs directory? I imagine there are given the ruleset.xml file obviously exists, but worth checking permissions maybe.

I've cloned the CakePHP coding standard repo and can use it as a custom coding standard when specifying the full path. Are you able to specify the full path to the CakePHP directory and have it work on your Mac?

If so, I'll need to check a composer install of the CakePHP standard and see where the files are going. If you can provide your composer file, that would be very helpful. I wont get a chance to look at it tonight, but I will try for tomorrow.

from php_codesniffer.

Yep the Sniffs are in the folder.
I have run PHPCS with the full path:

./phpcs -s --standard="/Users/toby/.composer/vendor/cakephp/cakephp-codesniffer/CakePHP" /Users/toby/Server/Sites/events/Controller/EventsController.php

And it still reports no errors, and still doesn't load the full 65 Sniffs...

This is my main composer file:

{
    "require": {
        "phpunit/phpunit": "3.7.*",
        "squizlabs/php_codesniffer": "*",
        "cakephp/cakephp-codesniffer": "*"
    }
}

The thing that is confusing me is that I installed them in basically exactly the same way, and am running them the same way... I'm wondering if it's some path setting or the like?

from php_codesniffer.

I have found the issue!!

So basically, if you install the Standard into your .composer folder it is 'technically' in a hidden folder and line 710 of CodeSniffer.php filters Sniff paths out that are in hidden folders.

Simple fix is to install the standard somewhere else! All working as expected now!

from php_codesniffer.

Sorry, I should have remembered this one. Someone else had the same problem and I've committed a fix that was contributed to solve this issue. Now, only the top most directory is checked to see if it is hidden.

The fix will be released in the next versions, hopefully released this week or next.

Thanks for all the help sorting this out.

from php_codesniffer.

No worries! Thanks for your swift support and help! Keep up the fanastic work!

from php_codesniffer.

For my projects I specify dependency on a coding standard in project's own composer.json like so: https://github.com/qa-tools/qa-tools/blob/develop/composer.json#L29

from php_codesniffer.

Yeah that idea did cross my mind, but I use the same standard for a range of projects so decided it was overkill...

from php_codesniffer.

However to make sure, that both standard parts work (one that doesn't fix and one that fixes) I had to ensure that:

1. I run tests for standard in both PHPCS versions: https://github.com/aik099/CodingStandard/blob/master/.travis.yml#L9-L11
2. I collect coverage information that is combined from multiple test runs

from php_codesniffer.

Since error reporting code is usually buried deep in the sniff code the idea of having 2 different classes where I have sub-class for PHPCS 2.x that does fixing seemed like too much to me.

from php_codesniffer.

That's great - not sure what it has to do with this issue tho?

from php_codesniffer.

Ah, there was another issue where guy wanted to make sure standard works across different PHPCS versions. I guess I've added comment to wrong issue :)

from php_codesniffer.

I'm having the same issue here. I'm using phpcs with WordPress Coding Standards.

I've installed phpcs on Mac Yosemite, another Ubuntu Laptop and Ubuntu server of Digital Ocean.

On Ubuntu machines, phpcs shows proper error reporting on terminal. But on Mac, it doesn't show errors even though I explicitly know that I've made an error.

I've checked about the hidden folder with .composer. It seems that I do not have that kind of setup. Because, I've phpcs and wpcs installed parallel under same directory(not hidden). And then I'm setting up the configuration of installed_paths using following command.

$PHPCS_DIR/scripts/phpcs --config-set installed_paths $WPCS_DIR

Any help would be appreciated.

from php_codesniffer.

@desaiuditd if you think different PHPCS installs are processing your files differently, use the -vv command line argument. This will output a lot of stuff (run it on a small file) but the top bit is the most important. It will show you what ruleset it processed and exactly how it processed it, including all the sniffs and settings it used.

If these looks exactly the same, run phpcs --config-show on all installs and make sure the output is also the same.

from php_codesniffer.

Hi @gsherwood Thanks for reverting back.

I checked up the same following the above discussion. Here is the diff report between two installs.

Verbose Output: https://www.diffchecker.com/iqnwn0y2

Configs: https://www.diffchecker.com/jb6as1pm

It looks like they both are same except the path where I've installed them.

from php_codesniffer.

I see 2 extra spaces on right side, when processing tokenized file.

from php_codesniffer.

Is it a significant diff ? I mean, I thought it is a part of source code file, so it should not matter.

from php_codesniffer.

If the PHPCS config, sniffs used, file analyzed are the same, then result should be the same. Such small diff in analyzed file might cause sniff to behave differently.

Try using file with 2 extra spaces on other computer.

from php_codesniffer.

The indentation of the 2 files looks different. If you check line 104 of your output, you see:
Process token 18 on line 13 [col:1;len:2;lvl:0;]: T_INLINE_HTML => ·· and
Process token 18 on line 13 [col:1;len:4;lvl:0;]: T_INLINE_HTML => ····
This is the token that the error is being generated on.

Thanks for posting that output. The problem with the code you've posted is very clear from it:

You've told PHP_CodeSniffer to use a tab width of 4 spaces, so the second bit of code is converted from 4 spaces into a single tag. But the first bit of code only has two spaces, so it is not a full tab wide. It is not converted at all, and left as 2 spaces. So PHPCS is comparing 2 spaces vs 1 tab.

Because of this, PHPCS is generating an error for the first piece of code (it is using 2 spaces for the line indent instead of a tab) but the second looks fine once spaces are replaced with tabs.

If you want to generate the same errors, you can do one of two things:

1. Set the tab-width setting to 2 for the first bit of code
2. Stop using tab-width all together and let the spaces cause errors in both pieces of code

For other code you are checking, I'm not sure if this will be the problem (I'd have to see the output when run on that specific code) but I can tell you that your PHPCS installs are working correctly from what you have been able to post.

from php_codesniffer.

True. And I tried the same thing. My files are under version control. And on both the machines I pulled the same commit and checked up. I guess all other errors showed correctly except only one thing below.

There are a few files with .php extension which does not hold any php code in it. The linux environment shows these errors for 5-7 files in the codebase but Mac doesn't show them at all.

----------------------------------------------------------------------
FOUND 0 ERRORS AND 1 WARNING AFFECTING 1 LINE
----------------------------------------------------------------------
 1 | WARNING | No PHP code was found in this file and short open tags
   |         | are not allowed by this install of PHP. This file may
   |         | be using short open tags but PHP does not allow them.
----------------------------------------------------------------------

So is this particular ruleset is supposed to be special or am I missing something on this again ?

Thanks for the clarification though, @gsherwood @aik099

from php_codesniffer.

Here's the diff for the above issue with no php code issue. https://www.diffchecker.com/6jwfupky

from php_codesniffer.

Are the short_open_tag settings of your PHP installs different by any chance? Maybe run php -i | grep short_open_tag on both to have a look. PHPCS will only add that error for empty PHP files if short open tags are OFF on your PHP install.

Note that you can mute that error in a custom ruleset.xml file by setting the severity of the Internal.NoCodeFound error code to 0.

from php_codesniffer.

Ah ! Tricky Catch. Thanks again. Help much appreciated. 👍

from php_codesniffer.

No problem, glad we've worked it out.

from php_codesniffer.