GunFire - the GPL chip programmer software

What to do if you want to help out on this project (coders)

I'm afraid that until I've got release 0.1 out the door, there isn't much anyone can do to help me. I really do have to sort this by myself, so that I can set up most of the structure which everything else will use. This isn't something that anyone could help out with, unless they happened to be working in the same room as me!

Please don't be put off by this though. If you would like to help out, please let me know and I'll drop you a line when release 0.1 is done.

The GunFire code is exclusively C++. You can use any language you like for the DLLs to support devices/adaptors/programmers, but the main GunFire code must be C++. Some compilers (eg. MS Visual Studio) can handle mixed-language code easily, but others can't. Since this is to be a cross-platform project, I'd like to keep this just C++.

If you do want to help out and would like to know where you can start, check the planned releases. I'm open to discussion if you want to do something which isn't planned for the next release - this list is just my current "gut feeling".

Note that although I need to get GunFire done on my own for the first stage, the PortIO project (which GunFire uses) can definitely use people to help out. If you're good at Windows hardware interfacing (particularly if you know device drivers) then please, go there and give a hand!

Coding guidelines

Follow the Mozilla coding guidelines where possible. This should stop any problems with obscure corners of the language causing problems.

Use the types defines in "types.hpp" instead of built-in C++ "int" types. We can change the typedefs in "types.hpp" to match the integer length for a specific platform, so that we never get caught with bugs like "int" changing from 32 bits to 16 bits and giving resultant overflow errors, or similar silly problems.

Use defensive coding. For example, if a function returns an error status, check it. Even if you've written that function, and you're sure an error can't happen, check it anyway - someone may change the function later, and your higher-level code could then die horribly. Most of the flakiness of Windows programs is caused by people ignoring this kind of thing. My main requirement for a good piece of code is that after it's written, I shouldn't have to look at it ever again for the rest of the project, so I will always favour slow and solid over fast and flaky!

Please, please, comment your code. Don't just say what it's doing, but also why. In general, over-commenting is better than under-commenting.

Lastly, always remember that the best software design tool is a Word document or sheet of paper, a brain and a bit of time to think about things. Personally, I plan a lot of design stuff in the bath. :-) Just don't reach for the text editor straight away, is my point.

What to do if you want to help out on this project (non-coders)

If you don't have C++ skills, you can still help from version 0.1 onwards by trying out the code, if you have suitable programming hardware (initially a ProPIC2 programmer and a PIC16F877). Or you also help by letting me know if you have any really neat ideas for features which I haven't thought of. I can't guarantee that your idea will make it to code, but if they're good then they'll probably go in at some point.

I haven't yet set up the SourceForge forums so that people can post suggestions. This will happen at some point in the near future. Until then, you can contact me via SourceForge on the link above.