Skip to content

Report verbosity of phpcbf #699

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Kolyunya opened this issue Sep 11, 2015 · 9 comments
Closed

Report verbosity of phpcbf #699

Kolyunya opened this issue Sep 11, 2015 · 9 comments
Milestone

Comments

@Kolyunya
Copy link

I think that phpcbf should have an option to configure it's output verbosity like one that phpcs has.
For example I usually don't want to see a list of files which were not affected by the phpcbf.

@Kolyunya Kolyunya changed the title Report configuration of the phpcbf Report configuration of phpcbf Sep 11, 2015
@Kolyunya Kolyunya changed the title Report configuration of phpcbf Report verbosity of phpcbf Sep 11, 2015
@aik099
Copy link
Contributor

aik099 commented Sep 11, 2015

Please post current report output and proposed report output.

@Kolyunya
Copy link
Author

@aik099 in my opinion a summary report type like one the phpcs has would be handy.
It should contain only a list of files which were actually affected by the phpcbf and a number of errors and warnings fixed.
Also I think a verbose report type should be implemented. It should contain only files affected by the program and a list of issues fixed.

What I'm trying to say is that it's not always useful to see ten screens of files which were not even affected by the phpcbf.

@aik099
Copy link
Contributor

aik099 commented Sep 11, 2015

Since phpcbf prints output in real time then not showing files with no violations would create delays in the output, which might be confusing to the reader.

@Kolyunya
Copy link
Author

@aik099 phpcs also has some delay when --report=summary is used. I personally don't think that this is confusing.

@gsherwood
Copy link
Member

Sounds like a really good idea, but probably a lot of work as I'd want to support all existing report formats (or all the ones that make sense at least). The current output could be shown when using the -v flag, as PHPCS does for per-file processing. I'm not sure there will be any need for -vv or -vvv yet.

@bbashy
Copy link

bbashy commented Jul 14, 2016

Been searching for this option but appears it's not something that's settable.

The output just lists all the files it processes and in my eyes, you should just see the ones it can/will fix for you.

This over and over is annoying to look at when you just want to see a simple output.
Processing SomeFile.php [PHP => 538 tokens in 87 lines]... DONE in 6ms (0 fixable violations)

@gsherwood
Copy link
Member

The output just lists all the files it processes and in my eyes, you should just see the ones it can/will fix for you.

By the time it has figured out if there are fixable errors, the debug output has already been suppressed. So it actually can't do what you are asking. Note that this is exactly the same as the -v option in PHPCS.

The difference between PHPCS and PHPCBF is that PHPCBF basically has the -v option hard-coded and it doesn't have any reports. You could certainly turn verbosity off, but I'd need to provide a way for PHPCBF to display the list of files, number of fixes, number of unfixed errors etc in a variety of report formats.

@gsherwood
Copy link
Member

I've been thinking about this again and I think a full range of reports is just too complex. I'll try and support verbosity, progress information, and print a basic summary report.

@gsherwood
Copy link
Member

I've pushed a commit that changes the output of PHPCBF. By default, it will just print a summary report about what it did. But you can also ask for progress information and for verbose information (as it did already).

The basic usage now starts with running PHPCS and getting some errors:

$ phpcs
.EE......................................................... 60 / 69 (87%)
.........


FILE: src/Reports/Cbf.php
------------------------------------------------------------------------------------------------------------------------------------------------------
FOUND 5 ERRORS AFFECTING 2 LINES
------------------------------------------------------------------------------------------------------------------------------------------------------
  83 | ERROR | [x] No space found before comment text; expected "// file_put_contents($newFilename, $newContent);" but found
     |       |     "//file_put_contents($newFilename, $newContent);"
  83 | ERROR | [ ] Inline comments must start with a capital letter
  83 | ERROR | [ ] Inline comments must end in full-stops, exclamation marks, or question marks
  83 | ERROR | [x] There must be no blank line following an inline comment
 174 | ERROR | [x] Line indented incorrectly; expected at least 8 spaces, found 4
------------------------------------------------------------------------------------------------------------------------------------------------------
PHPCBF CAN FIX THE 3 MARKED SNIFF VIOLATIONS AUTOMATICALLY
------------------------------------------------------------------------------------------------------------------------------------------------------


FILE: src/Fixer.php
-----------------------------------------------------------------------------------
FOUND 3 ERRORS AFFECTING 2 LINES
-----------------------------------------------------------------------------------
 146 | ERROR | [x] Line indented incorrectly; expected 8 spaces, found 12
 146 | ERROR | [x] Closing brace indented incorrectly; expected 8 spaces, found 12
 151 | ERROR | [x] No blank line found after control structure
-----------------------------------------------------------------------------------
PHPCBF CAN FIX THE 3 MARKED SNIFF VIOLATIONS AUTOMATICALLY
-----------------------------------------------------------------------------------

Time: 645ms; Memory: 24Mb

Then run PHPCBF and get a summary report of the fixes it did:

$ phpcbf

PHPCBF RESULT SUMMARY
----------------------------------------------------------------------
FILE                                                  FIXED  REMAINING
----------------------------------------------------------------------
src/Reports/Cbf.php                                   3      2
src/Fixer.php                                         3      0
----------------------------------------------------------------------
A TOTAL OF 6 ERRORS WERE FIXED IN 2 FILES
----------------------------------------------------------------------

Time: 1.77 secs; Memory: 6Mb

You can also run PHPCBF with progress output, where F means "fixed" and E means "error while fixing":

$ phpcbf -p
............................................................ 60 / 69 (87%)
..F..F...


PHPCBF RESULT SUMMARY
----------------------------------------------------------------------
FILE                                                  FIXED  REMAINING
----------------------------------------------------------------------
src/Reports/Cbf.php                                   3      2
src/Fixer.php                                         3      0
----------------------------------------------------------------------
A TOTAL OF 6 ERRORS WERE FIXED IN 2 FILES
----------------------------------------------------------------------

Time: 1.77 secs; Memory: 6Mb

If you want the old output, you can use the -v command line argument.

I think this is the best I can do for now. You can't pick from a list of reports, but I don't think that is as important for PHPCBF as it it for PHPCS and most people don't automate the fixing using build scripts.

All this will be released in 3.0.0a2, or is available on the 3.0 branch now. I had to refactor the way things worked, which was a bit risky for 2.x.

jrfnl added a commit to jrfnl/PHP_CodeSniffer that referenced this issue Nov 27, 2024
…y-php-statement

Generic/EmptyPHPStatement: improve code coverage
jrfnl added a commit to jrfnl/PHP_CodeSniffer that referenced this issue Nov 27, 2024
Follow up on squizlabs#699

Commit 529bcba7a42ec35873c31459ae61bee67852e956 removed the unreachable `default` case from the `switch`, but even when it is not explicitly there, this still leaves an unreachable branch in the code flow.

This commit takes the previous change one step further and removes the `switch` completely in favour of two separate `private` functions which each handle one specific token.

N.B.: this commit will be easier to review while ignoring whitespace changes.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants