Guidelines

Follow the Google C++ Style guide's recommendation for formatting,  https://google.github.io/styleguide/cppguide.html#Formatting . The exception is that lines may exceed 80 characters.

When transporting code from the decompilation into Ironfist, apply the "Does this look like code I would have written myself?" test. Decompiled code has a lot of features that are hard to read that are seldom seen in human-written code, such as gotos, lots of pointer arithmetic, automatically-generated variable names, etc. It's important to clean this up before merging it into the Ironfist codebase.

For includes: Have your includes from standard libraries, 3rd party libraries, and Ironfist code in three separate sections, separated by whitespace. Within each section, have all includes in alphabetical order.

Functions which are not intended for use outside the file where they are defined should be marked static.

CodeSynthesis XSD

The XML processing codes are generated by CodeSynthesis XSD, version 3.30. To automatically generate the code, run

xsd cxx-tree --generate-serialization filename.xsd

This will generate two files: filename.hxx and filename.cxx.

The filename can be creatures_xml or map_xml.

Strings

The game relies exclusively on C-style strings, but std:string, although it has problems, is generally much more pleasant to work with. Here's our compromise:

• char* ‘s may be used when they are simply passed from one function to the next, including the common case of just passing a string literal to DisplayMessage. However, if any manipulation is performed on that string, the surrounding code must use C++ strings
• Commonly-used API functions such as H2Message should be overloaded to also accept an std:string

• Except for special exceptions, method that need to return strings will return the actual values (not pointers/references) so as not to worry about memory management, favoring ease of use over efficiency

• Data structures taken from the original game will continue to use character arrays as fields unless all dependence of the original code on that field or its size have been eliminated. We will not make an active effort to do this at all possible places

Workflow

Ask to be added as a contributor to the Ironfist repository in Github. When adding a new feature to Ironfist, use this workflow in git:

1. Create a new branch in git, named <your initials>-<name of feature>. So, for example, if James Koppel wants to write the code for a "first strike" creature ability, he would run the command git checkout -b jk-first-strike
2. Write all your code and commit it to this branch. Be sure to commit often, preferably each distinct chunk of work, to make following the history easy.
3. When you're done, use git push to upload your code to Github, go to the Github website, and create a pull request against the master branch
4. Ask your teammates for a code review, and make more commits to respond to any feedback they may have
5. Once you have gotten the thumbs up, merge in your changes. Congrats -- your code is in the game! 

Misc

• All line endings should be Windows-style CR/LF line endings. We have a .gitattributes file in place that tells git to automatically convert all files; you should never have to worry about this.