...
- Coding style. All of the RAMCloud code uses a common coding style; there is some information about our style on this Wiki at Coding Conventions and Style Guide, but the ultimate source of truth is the existing code. Compare your code with existing RAMCloud code and make sure that your style conforms in every way: indentation, variable naming (e.g. camelCase, not underline_separators), location of curly braces, etc. You may feel that there are better ways of doing things than the way we have done them, and you may well be right, but please follow our conventions anyway: the most important thing is that the code has a uniform style, and there is no agreement about which style is best.
- Documentation. We have fairly extensive internal documentation for RAMCloud. Every class, every instance variable of every class, and every method must be documented. We use Doxygen format for our documentation. See Documentation Guidelines and Amendments to Current Documentation and Testing Guidelines for additional information about how to write documentation. Please make sure that your documentation is at least as good as the existing documentation and code.
- Unit tests. All code must have unit tests with 100% test coverage by lines; the only exceptions are for a few low-level modules where it is difficult or impossible to write meaningful unit tests (e.g., some NIC drivers). We use Gtest as the framework for our tests. Please follow the style for the existing tests. The most important thing is that tests are isomorphic to the code. This means that there is one test file for each source code file; within each test file, the tests are grouped by the method they are testing, and the order of the tests reflects the order of the methods within the source file. The tests for each method are ordered according to the lines of code within the method that they test. This isomorphic approach makes it relatively easy to tell whether a particular piece of code is properly tested, so we can maintain coverage as the system evolves. We use a white box approach to tests, where we write the tests while looking at the code, to make sure we have tested all of the code.
- Performance. RAMCloud's main claim to fame is its performance. Unfortunately, performance is very difficult to maintain: most enhancements tend to make the system slower. When making changes, please think about the potential performance impact, and run tests to make sure you have not damaged performance. We have two performance test suites that you can run before and after changes to make sure you have not introduced performance problems. The "clusterperf" tests run on a RAMCloud cluster to do system-level tests such as read and write operations. The "perf" tests measure the performance of low-level system components, such as Buffer manipulation; these tests run on a single isolated machine. We record the results of both of these test suites on this Wiki from time to time (see clusterperf benchmarks and Perf benchmarks], so you can see how your performance compares to the numbers we have measured.
- Open source license: for us to use your code, it must use the same open source license that we use on the rest of the RAMCloud code. You may change "Stanford University" in the copyright notice to your name, or the name of your organization, but the rest of the notice must be exactly the same as what we are using elsewhere in the code. It's up to you to make sure you have received any appropriate organizational permissions, and that your code does not infringe on any other copyrights or licenses.
Here's how things will work if you would like to contribute enhancements to RAMCloud:
...