Good Development Practices for Open-Source Developers
Use GNU Autotools autoconf, autoheader, automake. Configuration choices should be made at compile time. People building from sources today expect to be able to type configure; make; make install and get a clean build. The software must be able to determine for itself any information that it may need at compile- or install-time.
Test your code before release.
A good test suite allows the team to easily run regression tests before releases. Create a strong, usable test framework so that you can incrementally add tests to your software without having to train developers in the specialized intricacies of the test suite.
It is good practice, and encourages confidence in your code, when it ships with the test suite you use, and that test suite can be run with make test.
Sanity-check your code before release.
Use every tool available that has a reasonable chance of catching errors a human would be prone to overlook. The more of these you catch with tools, the fewer your users and you will have to contend with.
If you're writing C/C++ using GCC, test-compile with -Wall and clean up all warning messages. Run tools that look for memory leaks and other runtime errors; Electric Fence and Valgrind are two good ones available in open source.
For Python projects, the PyChecker program can be a useful check. It often catches nontrivial errors.
If you're writing Perl, check your code with perl -c (and maybe -T, if applicable). Use perl -w and 'use strict' religiously.
Spell-check your documentation and READMEs before release.
I would say most of these practices are not only good for Open-Source Developers, all developers could take benefit from them.
This is a 3th post with guidelines out of Eric Raymond's excellent book "The Art of Unix Programming". Read also:
- Basics of the Unix Philosophy
- Design Rules for Textual Data Formats
Some more posts with guidelines out of the book will follow next year, keep in touch.
Digg this story