You are currently accessing a test version of the comses.net website. Information that you
view or store here will not be preserved and may not be consistent.
Guides to Good Practice
Guides to Good Practice
We strive to foster and support good practices for developing and disseminating open and reproducible computational models. If you have any suggestions or corrections to make, please
let us know.
Other organizations focused on improving computational literacy and practices:
Agent-based model development
Keep your models simple
Document your models using
ODD or equivalent documentation protocol Consider carefully how to evaluate and validate your model’s outputs. Make sure you do a proper sensitivity analysis!
Structure your model into coherent modules where possible with well-defined inputs and outputs between modules.
Additional ABM Guides
Some of the code and data management practices listed below are also described in greater detail in
. Good Enough Practices in Scientific Computing by Wilson et al
License your models with an appropriate
Open Source license. Note that Creative Commons licenses are and will be deprecated and removed from not recommended for software comses.net in the near future. Use a version control system diligently, and strive for small, focused changes with meaningful and descriptive commit messages.
Clearly document external software and data dependencies with pinned versions (e.g.,
Docker, pip/ poetry, packrat, Maven/ Ivy, npm) Strive for simple, well-commented, self-documenting code with meaningful variable names
Adopt or develop community documentation standards to describe your computational models (e.g.,
ODD) Adopt a consistent, self-describing
directory structure for your code, data, documentation, and results
Archive your software in a DOI-issuing repository that provides citable URLs for specific versions of your codebase (for more details, see the Force11 software citation principles) An excellent collection of software deposit guidance from the UK’s Software Sustainability Institute:
https://softwaresaved.github.io/software-deposit-guidance/ Provide clear example test cases, sample inputs and expected outputs
Use relative paths, not absolute paths when referring to input or output data files
Structure your code with clarity, reuse and future comprehension in mind and adopt your modeling language’s idioms for writing clean, concise, and well-encapsulated code
Common Software Quality Assurance Baseline Criteria for Research Projects group. Data management
you'd like to know more information about what data we collect and why, please see
. If you continue to use this site, you consent to