We've seen the basics about patches: what they are, how they work, and how to create them. Now, I'm going to give you some tips to make your patches better.

First: change a single thing per patch, so that it can be handled on its own. For example, if there are two bugs in a single file, create two different patches that fix them independently (and submit the two in different bug reports>; see this post). Or if you are adding features, keep each feature in its own patch, except if they are highly related. In fact, this tip is not always a must; you should only care about this one if you are going to submit the patch back to a software developer.

Second: do not modify lines when you don't need to - i.e., keep your patches minimal. For example, if you are fixing a bug in a function, do not try to repair trivial stuff in other parts of the file, like removing empty lines, fixing typos in comments... I know, sometimes these happen by mistake.

Third: respect the style - indentation - of the original file. If it uses spaces instead of tabs to indent, use spaces. If lines are indented with four spaces, use four spaces in your changes... and so on. This is a general rule when modifying others' code; a single file with different indentation styles is very hard to read.

Fourth: always review your changes through a patch - that is, search for useless/incorrect chunks. When working on a project handled by CVS, it's a very common practice to modify a file and commit it afterwards. Running cvs diff in the middle allows you to catch stupid mistakes 990f the times. You see, understanding patches is also good even if you don't need the patch file for anything ;-)

Well, I think that's enough for today, as nothing else comes to mind. If you have any other suggestion, please share it!

Comments from the original Blogger-hosted post: