[ACCEPTED]-Should I commit cosmetic changes?-commit

If you are changing the code file, I don't 7 really see why you wouldn't want to commit 6 and share those changes. If you don't you 5 run the risk that someone else will fix 4 them and then collide with yours.

If they 3 aren't changes that other users want in 2 the codebase, perhaps you should ask yourself 1 why you are spending time writing them.

Do commit them, with the commit comment 7 flagged appropriately to make it easier 6 to ignore when skimming through a list of 5 changes.

Don't commit them in the same operation 4 as a change to functionality. That way, if 3 you do break something, it is easier to 2 narrow down what broke it and is easy to 1 revert just the refactoring if necessary.

Don't commit them together with unrelated 5 fixes.

I would commit them, but add some 4 predefined keyword to the commit message. Messages 3 with this keyword could then be ignored 2 when generating change logs.

You could use 1 a prefix like [cleanup] for instance.

[cleanup] Removed some whitespace
[cleanup] Changed format
Fixed some major bug.
[cleanup] Corrected indentation

On projects where I'm the only developer 8 I tend to do these kind of fix ups along 7 with other code changes.

On projects where 6 there's a team of us I tend to try and commit 5 these kind of changes on their own so that 4 they don't obscure the 'real work'.

I feel 3 that it's important to fix everything that's 2 'wrong' with a codebase even if it's purely 1 minor things like indentation.

I think this depends on your work environment 22 and how others working on the same project 21 want to deal with that which is likely to 20 differ.

So, my general suggestion would be 19 to ask the people working with the same 18 code and coming up with a guideline for 17 cases like that. You might find that people 16 don't mind check-ins due to cosmetic changes 15 or that they would rather live with a bit 14 of "unprettiness" rather than dealing with 13 cluttered change logs.

A definitive guideline 12 that is transparent to everyone is the best 11 way to deal with these questions and avoid 10 confusion in the future.

Personally, I like 9 tidied up code and wouldn't mind check-ins 8 due to purely cosmetic changes. However, if 7 it is just a bit of spacing and line breaks, I 6 would probably just let it be and only change 5 it if I was working on the same code file 4 anyway. I often remove and sort usings because 3 I find it confusing if there are a whole 2 bunch of usings that don't make sense, but 1 that's just me.

There's a couple of issues.

First, don't 23 do changes to the code because you're bored 22 and doesn't have enough real tasks. If this 21 is the case, go talk to your project manager 20 and get some real tasks assigned to you, something 19 with value.

In other words, don't go changing 18 the code for the sake of the change. Always 17 add some value to the code in the process.

Now, if 16 those changes are contributing to making 15 the code easier to handle, by you, and others, then 14 do them. Things like ensuring naming standards 13 are followed, refactor crufty code, etc. But 12 get a task for it, so that your project 11 manager can say "Yes, this is good, spend 10 2 hours on this and get back to me."

Commit 9 the changes when you're done with them. Don't 8 lop them together with whatever real task 7 you finished just before them, or the next 6 one, it will make merging bugfixes between 5 branches, code reviews, and just general 4 code browsing, hard to follow.

"Ok, so you 3 fixed bug 7711, and also changed about 100 2 other files. Nice, so what is actually the 1 bugfix here?"

I think when you’ve got a team of developers 11 working on the same code, the most important 10 thing is to agree a cosmetic style for code. So, your 9 first task is to try to get your entire 8 team to agree on a coding style.

Good luck.

Once 7 you’ve done that, commit cosmetic changes 6 as often as you want, to remind people to 5 stick to the style.

There’s a great section 4 in Code Complete about the merits of different 3 coding styles. If you can get your team 2 to read the section before your coding style 1 meeting, it might help to get you all out of the meeting alive focus the discussion.

Definitely commit them. If you commit them 6 along with real code changes and you have 5 to roll back those changes, then you lose 4 your cosmetic fixes.

Ideally, commits should 3 be like database transactions: a chunk of 2 related working code that can be rolled 1 back without affecting the rest of the system.

If the changes are to things which might 8 be in any way controversial (position of 7 brackets for example) then make sure you've 6 agreed a code style with the rest of your 5 team. Don't just change it to your own 4 preferred style then check it in. Otherwise 3 someone else might then change it back and 2 check their changes in, then you change 1 it back to your way...

Are these "minor" things fixes? If yes, commit 2 them. If no, don't.

Really, it depends on 1 what you and your team consider important.

i like to commit often. Certainly any time 7 there's an appreciable change. It's easy 6 that way. If you start to compartmentalize 5 code snippets and try and commit some sooner 4 rather than later you will eventually forget 3 to commit something very important.

In short: Commit 2 often and ALWAYS document the change. When 1 there's a HUGE change, tag it.

Don't commit just for the sake of commiting. I 9 usually add those for the code I'm working 8 on. For example if I'm fixing a bug in method 7 A I make sure to also make all cosmetic 6 changes as well.

IMO you guys are missing 5 coding tools like PMD, JIndent, etc that 4 take care of this issues as you code. Some 3 IDE's like Netebeans show this "issues" as 2 warnings. So its not a random/personal change 1 is following standards.