First, use doxygen to see a graphical representation of the code. Go to qwalk/src and type 'doxygen'. You need dot installed. Then find the 'graphical class hierarchy.' This is an incredibly useful device that lets you see the major players in the code. Particularly important class types are Method, Wavefunction/Wavefunction_data, Basis_function, and Sample_point/System. These are the ones that have the most children.

Coding

• Don't repeat code
• Use polymorphism and encapsulation judiciously
• Comments should say what you're trying to do

Don't repeat code

If you find yourself copy/pasting code, take the time to refactor it. Make a function or a class that implements the needed functionality and use that instead. It's worth it for maintenance and optimization reasons as well as improving the readability of the code.

Many problems have already been solved in the code. Keep this in mind and take a look around before reinventing the wheel. If you see a particular piece that could be extracted into a generic function or class, do so.

Polymorphism and encapsulation

Polymorphism is a powerful feature of C++, but it does come at a slight cost in efficiency, and it can be used to make the code too abstract. If the algorithm you're implementing is mathematical in nature, try to split the code where you split the math. That is, if there is a generic function, by all means use polymorphism (possibly just use the Basis_function class), as long as it doesn't affect the performance too much. Check this.

Encapsulation is the principle of separating different parts of the code as much as possible. Functions should have as few parameters and const parameters when possible. Global variables are not allowed (there are about three, but they're there for very good reasons). Do not depend on internal structure of other pieces of code. The ideal case is that for a piece of code, someone without any experience with QWalk can understand it without opening another file.

Tests

Test your code carefully, and make sure that you didn't break anything else! While we have not been particularly good at unit tests (method { TEST } is just about it), if you can think of a way to make a unit test for your code, do so.

Comments

Always document what you're trying to accomplish with your contribution and what the code is supposed to do. This includes how to use it. How you're accomplishing it can usually be understood from the code. If it's particularly tricky, document it.

General purpose libraries

• Basic capabilities : Qmc_std.h
• I/O: qmc_io.h
• Matrix algebra: MatrixAlgebra.h
• Random numbers: ulec.h