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

  • You need to elaborate on how your local rules are. – user1249 Nov 1 '10 at 9:47
  • 1
    I'm starting to be of the opinion that nobody should own code, much in the same way that a carpenter doesn't own the nails - he owns the bookshelf. "No, you can't remove that nail, I own it! I don't care if it's getting in the way of adding another shelf!" – Nate W. Mar 16 '13 at 20:55

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.

| improve this answer | |
  • Or fixes a bug... – Chinmay Kanchi Sep 15 '10 at 14:55
  • 1
    @Chinmay: assuming that fixing the bug actually improves the functionality of the program. A "bug fix" that amounts to a work-around for a bug in the editor's own code, or fixes one bug by introducing new ones indicates, at best, an inability to understand the code being edited: it may be a sign that additional documentation is needed, or merely that the editor needs to spend more time reading before attempting to write... – Shog9 Sep 15 '10 at 14:58
  • What about to change the indentation? is that right or wrong? – JD Isaacks Sep 15 '10 at 15:17
  • 1
    @John Right if the team standard is what you change it to. If your team doesn't have a standard I would suggest you get everyone together and make a standard. That way they don't see it as someone else just "messing with their code". Then, you have a documented reason why it needed to be changed. – Ryan Hayes Sep 15 '10 at 15:24
  • 2
    @John: it's irrelevant in most common (whitespace-agnostic) languages. But in something like Python it could change the behavior of the program: in that case, you'd call it based on whether or not the behavior changed for the better... Note that if your diff tools can't be instructed to ignore whitespace, it could be considered rude even for whitespace-agnostic languages (but then you should probably invest in better tools). And if the change consists of nothing but indentation changes, I'd classify that as "busywork"... – Shog9 Sep 15 '10 at 15:36

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).

| improve this answer | |

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.

| improve this answer | |
  • 1
    I can only confirm this opinion. There should be no such thing as my code and your code. The best method of code review is to have someone else work on your code. Of course, it doesn't mean you should barge in and make changes willy-nilly: before you make sweeping changes, at least check with your co-worker whether you understand his design correctly. – Cornel Masson Apr 21 '16 at 6:52

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.

| improve this answer | |

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.

| improve this answer | |

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.

| improve this answer | |

Not the answer you're looking for? Browse other questions tagged or ask your own question.