When is it right to edit the code written by a co-worker? [duplicate]

Question

This question already has an answer here:

• Is code ownership a code smell? 5 answers

For which issues is it right to edit the code written by a co-worker? For which issues is it wrong?

Answer 1

When it's right

When the edit improves the functionality of the program or makes the code itself more readable / maintainable.

When it's wrong

When the edit harms the functionality of the program or serves no purpose apart from providing the editor with busywork.

Answer 2

Who is the owner of the code? The company or the developer?

If the owner is (as usual) the company, there should be no difference in editing code written by you or by a coworker (unless a specific code maintenance policy).

Answer 3

Editing one other's code should be happening as the code evolves and should be encouraged as a practice so that you have collective code ownership.

The code should be owned by the whole team; having code that is only edited by (and therefore only really understood by) one developer is a bad idea. If you aren't in the code making changes yourself, you probably don't understand it. Waiting until the other developer leaves the company or gets sick is the wrong time to learn the code.

Having detailed unit tests in place and using source control should mean this practice is low risk.

Encouraging the whole team to follow Uncle Bob's "boy scout rule" and always trying to check in the code a little cleaner than you checked it out is a good way to ensure that the code stays clean over time and doesn't devolve into an unreadable, unmaintainable mess.

The only downside to this is if this practice turns into edit wars, where developers are constantly reverting one another's changes. This is probably a sign that you haven't decided on a coding standard for whatever is causing the edit war, so this would be a good opportunity to create one.

Answer 4

I would say it is right when what you are working on requires the change. It is right when you have been assigned to fix a bug and the bug is in that code.

If the code has nothing to do with what you are working on, but needs to be fixed, then bring it up to the team lead and let him assign a priority to fixing it and assign a person (it may not be you) to fix it. If he says not to spend your time on it, then it is worng to fix at that point. You are being paid to work on what you have been assigned to work on not what you want to work on. By all means bring it up that it needs to be changed, but priority setting is the manager's job not yours.

It is wrong to change working code just because of a personal preference.

It's wrong when you don't understand what problem the code was designed to fix or even understand the code. Just because it doesn't work for your needs doesn't mean you won't break something if you muck with it. If you need to change it to make what you are doing work, then go talk to the oreginal programmer about why he did what he did and what might be affected if you change it to meet your needs. NEVER change code you don't understand unless it is not working. This doesn't mean you don't ever fix the code, it just means that until you take the time to understand it thoroughly, you don't change it, especially if it is code already in production.

Answer 5

When is it right to edit the code written by a co-worker?

This depends on which phase the product is in. If the product is already stable and already released I would not make any changes that aren't needed unless there was a big change needed to really ugly code.

For which issues is it right to edit the code written by a co-worker?

I wouldn't nitpick about coding formatting. You should refactor when code is overly complex and needs to be changed anyway or is causing problems and never seems to work right.

Answer 6

Like stackexchange or wikis, you should be ready to share your code and allow anyone to modify it as long as the changes fits in the global design and goals. But ask yourself a question : why should someone have to modify someone else's code if it's not for debugging ? Have you clearly cut your project into pieces sufficiently to allow parallelization of coding through multiple programmers at the same time ?

If, at the same time, for different functionalities, you are forced to modify the same code as your co-worker, there is a code entanglement and bad "separation of concerns". You should revise your design to allow each programmer to work on different parts of the software code base.