Skip to content
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

Dump fixer #2218

Closed
wants to merge 4 commits into from
Closed

Conversation

akovalyov
Copy link

Resolution for #2195

@keradus
Copy link
Member

keradus commented Oct 12, 2016

  1. risky
  2. var_dump with 2nd parameter should not be removed

@SpacePossum
Copy link
Contributor

\a\b\c\dump($a);

should not be removed either.

There is some nice stuff in the AbstractFunctionReferenceFixer you could you use and make it more easy to do what you want :)

@GrahamCampbell
Copy link
Contributor

Dump fixer

Best name ever. 😆

$funcStart = $tokens->getPrevNonWhitespace($match[0]);

$funcEnd = $tokens->getNextTokenOfKind($match[1], array(';'));
for ($i = $funcStart + 1; $i <= $funcEnd; ++$i) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

*/
private function hasDump($content)
{
return false !== stripos($content, 'dump');
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this will make the fixing case sensitive (i.e. not remove Var_dump()),
removing this and using AbstractFunctionReferenceFixer will prevent this

@akovalyov
Copy link
Author

@keradus @SpacePossum sorry for being out of this PR for some time, but now I have a little bit of it to finalize it. But first I would like to hear your opinion - do you think it is needed in core and is there a chance for it to be merged? If yes - then I will proceed with comments resolution and any suggestions/comments which may raise, otherwise let's just close it. Looking forward to hear your thoughts on it!

@SpacePossum
Copy link
Contributor

IMO it is a very risky fixer going beyond the scope of the tool, i.e. fix code style and optimize code where possible. However the acceptable 'risky level' is of course opinionated.
But lets here from the community!

@GrahamCampbell
Copy link
Contributor

Yeh, this is very risky, because function calls affect the program state in PHP. Removing them could cause serious problems.

@GrahamCampbell
Copy link
Contributor

Not to mention, that statements can be used as well as just expressions, so even if php was pure, there could still be assignments within the arguments, affecting the state.

@GrahamCampbell
Copy link
Contributor

I'm 👎 on having this accepted as a cs fixer in here.

@akovalyov
Copy link
Author

I agree with you, that this too risky and is most likely out of scope of this awesome tool.
I've extracted it in small lib - https://github.com/akovalyov/DebugStatementsFixers. Those, who are interested, can always use that.
Thanks for your feedback and time!

@akovalyov akovalyov closed this Jan 28, 2017
@akovalyov akovalyov deleted the feature/dump-fixer branch January 28, 2017 13:34
@curry684
Copy link

As this issue is still high on the list when Googling for 'how to prohibit accidentally committing dump statements` - there is an awesome PHPStan plugin that allows you to define forbidden functions and constructs, and is out of the box default configured to do exactly what we want here: https://github.com/ekino/phpstan-banned-code

composer require --dev ekino/phpstan-banned-code

@kubawerlos
Copy link
Contributor

@curry684 you can even automate removing it with CommentedOutFunctionFixer and NoCommentedOutCodeFixer.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants