Some rules for maintaining this distribution (from the author)
--------------------------------------------------------------

Maintainers,

- When I first released Nighthawk in 1997, it was just me writing it. 
Now days, it's a collaboration. So, this file is to set down some 
guidance on maintaining this project.

- Please read and understand the licence of this distribution. In 
summary: Only use your own work or GPL (don't use commerical work). 
Reference/credit other people's work you use.

- Please initial and date your changes so we know what you changed. ie: 
"JN, 23AUG20"

- The code format has been Microsoft "C" formatting (most of the code in 
this source tree is still in this format. I haven't touched code that 
didn't need maintaining). In future I would like functions and methods 
be formatted to "linux kernel style". See:

https://en.wikipedia.org/wiki/Indentation_style#Variant:_Linux_kernel

- Regarding the above point, my flavourite Unix editor is nano. Tab 
intentions are totally reliable with any console based editor in my 
experience and unreliable with GUI editors. I hate editors that open the 
code and the intention is all over the shop. Yuck.

- Please DON'T "tidy up" code for the sake of it. I can't think of a 
better way to add random bugs into software than going through the 
source code and reformatting it. And so:

- If a function/method is changed from one release to other by 40% or 
more, then reformat to linux kernel style.

- If a function/method is very hard to read (due to multiple authors 
editting it), then reformat to linux kernel style.

    Nb/ BE CAREFUL. VERY EASY TO ADD BUGS !!

- Aim to have no more than 3 nests in functions/methods. The linux 
kernel style helps stop this. As Linus Torvalds once said: if you have 
more then 3 nests, you're screwed anyway.

- For each release, create and patch from the previous stable release and 
review the changes to check for any accidental code changes.

 eg: "diff -r ./nighthawk-3.0 ./nighthawk-4.0 >nighthawk_3.0_4.0.patch"

This is where initialing code comes into play. If a code change has 
occurred that is not initialed, then it's probably fat fingers, brain 
fade etc.

- Structured walkthroughs: This is pretty old school, but it works for 
me. After I write/modify code, I leave it for a few days, then proof 
read it (ie: walk through code like I'm the CPU).

- Over the past 30 years, The C++ extension that is implemented by g++ 
has turned into arse by its standards commitee. Maintaining C++ programs 
now days is becoming painful. Nighthawk uses the basic C++ features: 
Inheritance and polymorphism, and that's the way I would like to keep 
it. So, for any C++ programmers coming into this project, I would like 
Nighthawk to move away from C++ rather than emerse further into it. 
Anybody with experience with previous versions of this game will notice 
this version has C files now, as I have tried to move as much code as I 
can into the C space.

- I've added png_loader.c to get around bugs in xpm_loader.c and the 
fact that some bitmaps are getting big. xpm_loader.c will be kept for 
legacy (there is no need to touch the existing small xpm sprites like 
floor, droid, explosion, and door sprites etc). For new bitmaps, save 
them as png and use png_loader(). png_loader.c will scale all bitmaps so 
that width of bitmap is divisible by 4 (ie: a long word) to keep some 
OpenGL implementations happy.

- Testing (this is my recommendation to anything you develop based on my 
30 years as a programmer): Never make public any new version without 
thorough testing. Users don't tolerate buggy software (They will delete 
software and never return !). Test your changes for a week at least. If 
you find a bug, Fix it, repeat testing for a week with no bugs. Make a 
test plan on paper or in your head to test software so that all your 
code is tested. Use printf()'s if need be to ensure all your new code is 
being executed. Sometimes it is impossible to execute a state in 
software. In this case, you'll have to perform a functional test on that 
part of the code. After your own testing, give the software to a few 
people to test for at least a week. They will use program in a different 
way and perhaps trigger bugs. If it passes their usage with no bugs 
found (for at least a week), then make your changes public. Always go 
"gently, gently" with new software (or old software with major changes). 
Baby little steps !


:Jason Nunn
 13 Oct 2020
