Out of contributing graphics, sound, and code to XEvil, contributing code is by far the most difficult and risky. Contributing graphics and sound is pretty straight-forward. The worst that can happen is the colors look a little wrong, or the executable gets big because the sound isn't compressed much, or the look-and-feel isn't quite right. With code, you can destroy everything. Cause XEvil to crash, slow the game speed to a crawl, suck up excessive memory and system resources, break the build so XEvil doesn't compile on all platforms, destroy the architectural integrity of the codebase turning it into unmaintainable spaghetti. So, Satan takes this area very seriously. Continuous, iterative, incremental improvement is our only hope for salvation. Which leads to...Software should be written as carefully as English prose, with consideration given to the reader as well as to the computer.
[Grady Booch 1994, Object Oriented Analysis and Design, 2nd Edition]
Every time you touch the XEvil codebase, it will become more clean, more understandable, more well-commented, and more maintainable than when you found it.
[Satan 1998, The XEvil Developer's Page]
If you are an experienced programmer familiar with working on long-term team projects, you already understand the benefits and necessity of clean, consistent coding and the difficulty of managing changes and merging code. If you are a less experienced programmer, it will be a good educational experience for you, skills that will help you the rest of your career. Corollary #1 may become less true as you go through the process of integrating code into XEvil several times. But, it will be quite true in the beginning.Don't be surprised if you spend as much time and effort adjusting, merging, and testing your changes to get Satan's approval for check-in as you did making the changes in the first place.
[Satan, ibid.]
You can, of course, make hacks for your own use, for getting your code to work, and for experimenting with the XEvil codebase. However, you'll have to implement a clean solution before Satan will accept your code into the main XEvil distribution.No hacks.
Any large-scale software project will collapse under its own weight if it doesn't employ strict techniques for controlling complexity. The XEvil codebase has undergone continuous bug fixes and feature additions for four and a half years, has survived the transition from UNIX-only to UNIX and Windows cross-platform, from single-machine to network-play, and is still fairly clean, maintainable, and extendable. Software investment pays off.
Every single hack comes back to bite, eventually. Maybe tomorrow, maybe next month, maybe three years from now, but it will happen. And the cost of fixing the hack is more than gain from doing it in the first place. Sometimes you have no choice but to hack to meet time constraints or to do experimentation. This is unavoidable, but someday either you or someone else is going to pay for that hack.
Satan loves talking about XEvil software architecture and designs
for future work. If you get stuck on something and can't think of
a clean way of solving your problem, send mail to Satan.
He'd love to know what you're working on, and how you're thinking
of designing/implementing something. It's probably a good idea to
talk to Satan early in the process of making a modification to XEvil.
Satan might have some useful tidbit of information that will make your
job much easier. And, there'll be no nasty surprises when you ask
Satan to include your code in the main XEvil distribution. Remember:
Satan reserves the right to refuse changes for any reason whatsoever.
It's not because Satan is an asshole, it's because Satan wants the XEvil
codebase to be rock-solid with a very high degree of quality.