Skip to content

Latest commit

 

History

History
21 lines (17 loc) · 3.37 KB

CONTRIBUTE.md

File metadata and controls

21 lines (17 loc) · 3.37 KB
Raw

Contributing checklist

In terms of syntax, the only rule of thumb is to use descriptive variable names even if they end up being long. Otherwise, any preferred reasonable syntax will be accepted.

However, the we must put an emphasis on code testing:

  1. A unit test, integration test, or regression test accompanies the feature. This test should automatically fail when the code is erroneously changed. This mean that we should not return 0 or copy-paste the tested sections, since changes to the actual code will not affect the outcome of the test. Tests longer than a few seconds should be tagged as with the suffix MEDIUM, and tests a minute or longer should be tagged with LONG. Long tests are very undesirable and should be avoided when possible.
  • A unit test is often most appropriate, and is aimed at testing a single component of the code. See the test on Euler's primitive to conservative conversion
  • An integration test runs the entire main program by taking an input file and calling PHiLiP_1/2/3D. It should be derived from the TestBase class, and have a control file located in the integration test directory. Since integrations tests uses multiple components, they usually take longer. Furthermore, the cause of failure is sometimes less obvious. A good suggestion is to use an existing test control file, and only change 1 parameter to help pinpoint issues when it fails.
  • A regression test stores previously computed data to validate future results. Note that this type of test is rarely appropriate since valid changes in the code can fail this type of test. If implemented, a script/code should be made available such that newly computed results can replace the old results. See file1 and file2
  1. The feature has been documented.
  • Doxygen is currently used to generate documentation. Please visit their website to see how to properly document the code.
  • Function and member variable documentation should be presented in the associated header file. make doc should generate a html file in the /path_to_build/doc/html/index.html that can be opened used your browser of choice. A non-documented element will generate a warning, which in turn will fail the pull request test.
  • Comments in the .cpp code as appropriate, but prioritize self-documented code by assigning proper variable names.
  1. The master branch of https://github.com/dougshidong/PHiLiP has been merged into your fork and merge conflicts have been resolved.
  2. The entire ctest suite has been run in Release mode and the short/medium length tests have been run in Debug mode (using ctest -E LONG). Make sure that no tests fails other than the ones listed in the GitHub issues with testfail tags.
  3. Submit a pull request. Undocumented code will be automatically detected.