3 added 262 characters in body
source | link

You wrote

When someone says "this will need a lot of testing", I show them how I got there

So they could not get the information "how you got there" easily from the commit logs, you had to explain it to them? That gives me the impression your commits are too large, or your commit messages should be improved, or both. So I would recommend the following:

  • Separate refactorings strictly from changes which affect behaviour, and commit them individually

  • Avoid even committing multiple refactorings at once, especially when the affected code areas "overlap".

  • Make sure each and every refactoring you did is mentioned in your commit, and focus on writing why you changed something.

For example, when you change the name of a function or of a member variable which might affectwhere you have to touch multiple files, don't intermix this with an "extract function" refactoring. Instead, compile and commit the renaming first, thenand mention the kind of renaming (and maybe why you did it) in the log. Then make the "extract function" a separate commit, and mention for what reason you extracted the function. If, for example, you also removed some duplicate code by reusing the newly extracted function, that should be mentioned was well. If this remove of duplication will affect many locations in your code, consider to do it in a separate commit.

That way, if your reviewers have problems to understand your latest pull request, they can go through the commit log and follow the individual steps of your changes one-by-one.

You wrote

When someone says "this will need a lot of testing", I show them how I got there

So they could not get the information "how you got there" easily from the commit logs, you had to explain it to them? That gives me the impression your commits are too large, or your commit messages should be improved, or both. So I would recommend the following:

  • Separate refactorings strictly from changes which affect behaviour, and commit them individually

  • Avoid even committing multiple refactorings at once, especially when the affected code areas "overlap".

  • Make sure each and every refactoring you did is mentioned in your commit, and focus on writing why you changed something.

For example, when you change the name of a function or of a member variable which might affect multiple files, don't intermix this with an "extract function" refactoring. Instead, compile and commit the renaming first, then make the "extract function" a separate commit. That way, if your reviewers have problems to understand your latest pull request, they can go through the commit log and follow the individual steps of your changes one-by-one.

You wrote

When someone says "this will need a lot of testing", I show them how I got there

So they could not get the information "how you got there" easily from the commit logs, you had to explain it to them? That gives me the impression your commits are too large, or your commit messages should be improved, or both. So I would recommend the following:

  • Separate refactorings strictly from changes which affect behaviour, and commit them individually

  • Avoid even committing multiple refactorings at once, especially when the affected code areas "overlap".

  • Make sure each and every refactoring you did is mentioned in your commit, and focus on writing why you changed something.

For example, when you change the name of a function or of a member variable where you have to touch multiple files, don't intermix this with an "extract function" refactoring. Instead, compile and commit the renaming first, and mention the kind of renaming (and maybe why you did it) in the log. Then make the "extract function" a separate commit, and mention for what reason you extracted the function. If, for example, you also removed some duplicate code by reusing the newly extracted function, that should be mentioned was well. If this remove of duplication will affect many locations in your code, consider to do it in a separate commit.

That way, if your reviewers have problems to understand your latest pull request, they can go through the commit log and follow the individual steps of your changes one-by-one.

2 added 151 characters in body
source | link

You wrote

When someone says "this will need a lot of testing", I show them how I got there

So they could not get thisthe information "how you got there" easily from the commit logs, you had to explain it to them? That leadsgives me to the impression your commits are too large, or your commit messages should be improved, or both. So I would recommend the following recommendation:

  • Separate refactorings strictly from changes which affect behaviour. , and commit them individually

  • Avoid even committing multiple refactorings at once, especially when the affected code areas "overlap".

  • Make sure each and every refactoring you did is mentioned in your commit, and focus on writing why you changed something.

For example, when you change the name of a function or of a member variable which might affect multiple files, don't intermix this with an "extract function" refactoring. Instead, compile and commit the renaming first, then make the "extract function" a separate commit. That way, if your reviewers have problems to understand your latest pull request, they can go through the commit log and follow the individual steps of your changes one-by-one.

You wrote

When someone says "this will need a lot of testing", I show them how I got there

So they could not get this information easily from the commit logs, you had to explain it to them? That leads me to the following recommendation:

  • Separate refactorings strictly from changes which affect behaviour.

  • Avoid committing multiple refactorings at once, especially when the affected code areas "overlap".

  • Make sure each and every refactoring you did is mentioned in your commit, and focus on writing why you changed something.

For example, when you change the name of a function or of a member variable which might affect multiple files, don't intermix this with an "extract function" refactoring. Instead, compile and commit the renaming first, then make the "extract function" a separate commit. That way, if your reviewers have problems to understand your latest pull request, they can go through the commit log and follow the individual steps of your changes one-by-one.

You wrote

When someone says "this will need a lot of testing", I show them how I got there

So they could not get the information "how you got there" easily from the commit logs, you had to explain it to them? That gives me the impression your commits are too large, or your commit messages should be improved, or both. So I would recommend the following:

  • Separate refactorings strictly from changes which affect behaviour, and commit them individually

  • Avoid even committing multiple refactorings at once, especially when the affected code areas "overlap".

  • Make sure each and every refactoring you did is mentioned in your commit, and focus on writing why you changed something.

For example, when you change the name of a function or of a member variable which might affect multiple files, don't intermix this with an "extract function" refactoring. Instead, compile and commit the renaming first, then make the "extract function" a separate commit. That way, if your reviewers have problems to understand your latest pull request, they can go through the commit log and follow the individual steps of your changes one-by-one.

1
source | link

You wrote

When someone says "this will need a lot of testing", I show them how I got there

So they could not get this information easily from the commit logs, you had to explain it to them? That leads me to the following recommendation:

  • Separate refactorings strictly from changes which affect behaviour.

  • Avoid committing multiple refactorings at once, especially when the affected code areas "overlap".

  • Make sure each and every refactoring you did is mentioned in your commit, and focus on writing why you changed something.

For example, when you change the name of a function or of a member variable which might affect multiple files, don't intermix this with an "extract function" refactoring. Instead, compile and commit the renaming first, then make the "extract function" a separate commit. That way, if your reviewers have problems to understand your latest pull request, they can go through the commit log and follow the individual steps of your changes one-by-one.