What to do if a co-worker is editing your code just to change the appearance?

Question

What should you do, if a co-worker is editing your code?

Without the purpose of adding functionality or fixing bugs, just to change how it looks...

Answer 1

Talk to them about it. Go into the conversation with the attitude of "They're not doing this to annoy me or because they have some form of obsessive-compulsive disorder; they're trying to make my code better."

Because you could be wrong. That could be a subtle bug fix and you just didn't spot it.

Or, it could be that there's a coding standard you don't know about that you're violating, and they're just correcting it.

Or, it could be that they're trying to annoy you, or they have some form of obsessive-compulsive disorder. If that's the case, ask them nicely to stop, and if that doesn't work, take it up with your boss.

But you'll never know unless you ask.

Answer 2

I'm not so married to how my code looks for it to bother me. :) I try to learn from the changes. Did my coworker adjust variable names? Write a more efficient loop? Make the code more readable?

If I can't see how the changes improved what was already there, I usually ask the coworker who made the changes what the motivation behind them was. It's possible that the advantage is just not obvious to me. And if I'm right and they're wrong, then perhaps I can explain why I wrote it the way I did.

If all else fails, revert the check-in. ;)

Edit: All bets are off if the desire to make cosmetic changes introduced a bug, though.

Answer 3

IMO you and your team should be using a coding standard anyway. If this is the case, then the questions becomes 'did your original code conform to the standard?' If 'yes' then your colleague should not be touching your code unless to change it functionally. If 'no' then I'm afraid your colleague has every right to tidy up your code. As a project lead I find myself doing it all the time.

If you're not using a coding standard then the whole argument of what constitutes 'good code' becomes way too subjective. Hence why you should be using a coding standard :)

Answer 4

As one of those people (the people who occasionally reformat other people's code), the main reason I do it is readability. Some people are just extremely sloppy with their indentation or with mixing tabs and spaces.

The main thing I have a habit of changing is reducing long lines so that I can read the whole thing without horizontal scrolling. I'll break complex statements up into separate statements or reformat method calls/declarations to list one parameter per line if it doesn't all fit comfortably on a single line. I'll also edit comments, either to fix English errors or just to make things clearer.

Yes, I could leave it alone, but I'd rather reduce the mental effort required to read the code.

What should you do about it? Firstly, consider that maybe this person is making your code better. Also, you should ensure that you have some consensus in your team about how code should be formatted. If each person has different habits it will slow everybody down. If they are not making your code better and they are going against the grain, then you need to confront them about it. If that doesn't work then you might need to get others involved.

Answer 5

Ask them why they are doing it; a valid explanation may diminish your frustration, but you should let them know how much it bothers you. Who knows, maybe they thought they were doing you a favor and will stop when they learn it offends you. Or you may be dealing with someone who is truely suffering from a medical condition.

Answer 6

Is s/he allowed to? Do the changes improve the code? If so, swallow your pride. If you feel the code quality is worsened, take it up with the co-worker and ask them why they felt the need to change your code with no obvious benefit. If it's being done out of spite or because the person mistakenly feels they're better than you, and you can't work it out with them, take it up with your boss.

Answer 7

IDE's like Visual Studio have an option called Format Document that will format code according to the rules the user has set in the IDE. It could be your co-worker is using this (either automatically without knowing, or by deliberate application). Perhaps their IDE uses spaces instead of tabs, or vice-versa, and these are being applied automatically without even knowing? But you need to talk with them to find out.

Incidentally, I will often re-format code of co-workers if it is obviously not following some kind of formatting scheme (i.e. it is all over the place). It's a hopefully subtle way of making them notice. (However, I wouldn't reformat it if it was neat, but not to my liking).

Answer 8

If he's changing it so that it meets your team's coding standards, you should follow the standards next time.

If he changes it such that it no longer follows your team's coding standards, inform him what he's doing wrong and have him change it back.

...Your team does have a set of code formatting standards that are used by everyone, right?

Answer 9

I occasionally reorder code written by messy coworkers (or fix typos in comments). They know that I'm obsessive in code formatting and order and therefore they let me do that without complaining too much. Sometimes they also give me a free soda or cookie.

Of course this is occasional work, as it broke the "blame" functionality in SVN.

This is also a very basic way to do some kind of code review (I usually read most of the code committed by my coworkers in the modules I'm working on).

Answer 10

Code conventions is the answer. You should have one at work. If you don't, start right now (a good starting point is google style guide) . When there are written (or at least commonly known) rules the answer to your question is trivial.

Answer 11

I feel you are thinking it is offensive to do so... ? For example, I myself would immediately fix this code

int myFunction( ) {

    int i ;
  return  0;

}

to become

int myFunction() {
    int i;
    return 0;
}

so... should I be punished because of my action? In real life, I actually have tons of SVN logs read 'Formatting'. ;-)

Answer 12

Use a style checking tool

Start using StyleCop or similar and enforce code style rules and also make it an obligation for all developers to use it. All code will look the same without exception. And get together with wiseheads to discuss most appropriate rules for your organisation. Even though default rules are very similar to .net framework code itself already.

It's the easiest way of doing it. I found myself correcting someone else's code at one of my previous employers because this other guy was writing code with excessive amounts of empty lines and no indentation rules whatsoever. Code was actually unreadable by an average developer. If StyleCop would exist back then it would make many of us really happy.

Answer 13

this is a thought I saw on internet talking about refactoring and maybe explain why would someone touch your code to make it better:

Why?

There are two main reasons to refactor:

1. To improve the code/design before building on it’s top: It’s really hard to come up with good code on the first attempt. The first try to implement any initial design will show us that we misinterpreted or forgot some logic.

2. To adapt to changes in the requirements. Change happens in the software development; to be responsive to change is better to have a good code base. We have two options for both scenarios, path the code or refactor it. Patching the code will lead us to unmaintainable code, and will increase our technical debt, it’s always better to refactor.

When?

1. The sooner the better as is easier.

2. faster and less risky to refactor over a recently refactored code rather than waiting to refactor for the code to be almost completed.

What?

1. All the code and all the design are candidates for refactoring.

2. An exception for not refactoring something could be a working piece of code which is quality is low, but due to be close to a deadline, we prefer to keep our technical debt rather than risking the planification.

You just have to let him do his best, if it would be great for both and save your time in future!

cheers