I’d like to add one important point to Aaron’s list to good practices in open source software: extensive tests. Sure, manually testing the program is good, but since open-source software is done mostly by volunteers, tests that run by themselves are of great help. In the past, I have witnessed so many bugs in KOffice, including mine of course, that surely would be earlier exposed, had we an automated test suite for that.
This taught me first hand the importance of testing (unit test is the obvious choice, but even a bunch of plain assert()s is better than nothing), until I finally adopt the “if no test exists for this module, assume it’s broken” philosophy. For my personal projects, now I am very careful to make the corresponding tester for all modules/classes. That will save my days and reduce the headache later. It is funny to observe that the code which does the testing is sometimes longer than the code under test (though this fact definitely plays little role here).
Test suite is also very useful on stuff being developed by many people. Some day in the future, maybe the maintenanceship of your code is transferred to another person and when s/he wants to further develop it (implement feature, fix the bug, add workaround, you name it), the test suite will give early hints whether the new code breaks the regression or not. “But the code looks good (and I am a great hacker!)” just does not guarantee anything and completely antipodal to that broken philosophy I’ve mentioned.
Speaking about test, I can as well mentioned that it is a good idea to valgrindify the program from time to time. Ideally, after a feature is correctly implemented and does not break any tests, Valgrind should be used to point any possibilities of memory leaks and other similar mistakes.
Programming is 1% coding, and 99% debugging. You surely would appreciate any extra help for that 99% part, wouldn’t you?
So, happy testing.