Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

phpcbf only format changed code in file #1138

Answered by jrfnl
ecotechie asked this question in Q&A
Discussion options

Hi, I'm trying to figure out how I would be able to only have phpcbf edit the code that has been edited and not the whole file. I am working on a repo where some people have not followed any standards and it's a mess. However, we've agreed to hold of on a full repo lint for a while. In the mean time, I'd like my code formatted as I save the files, but not the whole file.

Mainly though, I'd like to be able to work on my other projects while using phpcbf. I have it setup to work on VIM (NixVIM specifically) and it's somewhat cumbersome to turn it off and on again.

You must be logged in to vote

@ecotechie This is currently not possible and also not desirable.

There are numerous sniffs which look at a file holistically or look at a larger part of the context in which code is used and a change on line 50, may cause a new error for line 20, so only fixing errors on the lines touches in a changeset is not a good idea.

Some examples:

  • A sniff checking the return type of a function is correct in the documentation - if the changeset introduces a new return statement with a different return type, the sniff may start flagging the line containing the @return annotation in the docblock, which was not part of the changeset.
  • A sniff which checks that there are no unused import use statements...

Replies: 1 comment

Comment options

@ecotechie This is currently not possible and also not desirable.

There are numerous sniffs which look at a file holistically or look at a larger part of the context in which code is used and a change on line 50, may cause a new error for line 20, so only fixing errors on the lines touches in a changeset is not a good idea.

Some examples:

  • A sniff checking the return type of a function is correct in the documentation - if the changeset introduces a new return statement with a different return type, the sniff may start flagging the line containing the @return annotation in the docblock, which was not part of the changeset.
  • A sniff which checks that there are no unused import use statements - if the changeset removes the last use of a certain class/function/const, the sniff will start throwing an error on the line containing the use statement, not on the lines touched in the PR.

Hope this helps explain the rationale behind this design choice.

You must be logged in to vote
0 replies
Answer selected by ecotechie
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Category
Q&A
Labels
None yet
2 participants

AltStyle によって変換されたページ (->オリジナル) /