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

[RFC] var_dump/dump fixer #2195

Closed
akovalyov opened this issue Sep 22, 2016 · 4 comments
Closed

[RFC] var_dump/dump fixer #2195

akovalyov opened this issue Sep 22, 2016 · 4 comments

Comments

@akovalyov
Copy link

This RFC is for var_dump/dump removal fixer. While a lot of devs debug via var_dump(or via Symfony/VarDumper dump), it is dangerous to have it in code, especially if it appears in production . So, why not to introduce these functions removal? What do you think?

@SpacePossum
Copy link
Contributor

SpacePossum commented Sep 22, 2016

Hi and thanks for your suggestion :)

How about var_export or the CURLOPT_VERBOSE flag?
The thing is that we would not be fixing code style, but modifying the way some code works. This is not always a bad thing IMO. However in this case we cannot determine if the var_dump is indeed a forgotten debug statement (and if the function is not overloaded) or is part of the logic that is essential to the application.
Therefor I would not add it to the core of the application because it is out of scope and risky. However such a fixer is relatively easy to write and can exists as a custom fixer for your needs.
But lets see what the community thinks :)

@akovalyov
Copy link
Author

akovalyov commented Sep 22, 2016

@SpacePossum thank you for your feedback.

I agree with you that such a functionality might be out of scope of the project.

Right now I can't judge what is more risky for developer - keeping statements in the code, which are commonly used for debugging (especially taking into account that i.e. dump won't exist in Symfony prod env), or use the fixer as such one.

However, I think that contrib fixers are usually enabled explicitly by developer, which means that one understands all the consequences of it.

Anyway, the reason why I've created the issue is that I've already done this fixer for private purposes. If community wants to have that, I will be more than happy to contribute to an awesome tool. If there is no need/it is our of scope of the project, I will just use my fork.

@akovalyov akovalyov mentioned this issue Oct 12, 2016
@buffcode
Copy link
Contributor

Also consider that those debug statements, especially var_export($var, true) could be used to save debug data / traces in production whenever an unexpected error occurs.

@akovalyov
Copy link
Author

Short summary from PR discussion - too risky to have it in core. For those, who want to have that - https://github.com/akovalyov/DebugStatementsFixers.

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

No branches or pull requests

3 participants