Geek Answers Handbook

Do refactoring and non-refactoring change as separate checks?

Do you mix refactoring changes with development / bug fixes, or do you keep them separate? Implementing large-scale refactoring or reformatting code that can be done with a tool such as Resharper should be kept separate from working with functions or bug fixes, because it is difficult to make the difference between versions and see real code changes among the many refactoring changes. Is that a good idea?

+4
source share
5 answers

When I remember, I like to register after refactoring in preparation for adding a function. As a rule, it leaves the code in the best condition, but without changing the behavior. If I decide to cancel this function, I can always save the best structured code.

+5
source

Keep it simple.

Each check should be a separate, one-time, gradual change in the code base.

This makes it easier to track changes and understand what happened to the code, especially when you find that some error occurred around the 11th of last month. Trying to find a one-line change among refactoring checks for 300 files really, really sucks.

+3
source

As a rule, I register when I did some part of the work, and the code returned to compilation / unit tests are green. This may include refactoring. I would say that it would be best practice to try to separate them. I find it hard to do with my workflow.

+2
source

I agree with the earlier answers. If in doubt, split your changes into a few commits. If you don’t want to clutter up the change history with a lot of small changes (and your changes look like one atom change), make these changes in the side branch, where you can separate them. It is much easier to read the differences later (and be sure that nothing was accidentally broken) if each change is clear and understandable.

Do not change functionality while correcting formatting. If you change the value of the conditional expression so that a whole bunch of code can be exceeded, change the logic in one change and perform outdent in the subsequent change. And be explicit with your commit messages .

+1
source

If the source code management system allows this. (This does not work in my current task due to the fact that the source control system is not like by one user who checks one file in more than one place.)

  • I have two working folders
  • Both folders are a check from the same branch
  • I use one folder to implement new changes in development / bug fixes.
  • In another folder, I do refactoring,
  • After each refactoring, I check the refactoring folder
  • Then update the new function development folder, which integrates in my refactoring

Therefore, each refactoring is in its own test, and other developers quickly receive refactoring, so there are fewer merging problems .

0
source

More articles:


All Articles