|
Introduction
|
Well-made software is easier to expand and reuse
You need to produce reproducible research.
You are a user of your own code.
|
|
Issues
|
Issues are a way of recording bugs or feature requests.
Issues can be categorised by type.
Issues can reference other issues, and be referenced by commits.
|
|
Project Management
|
Projects are broken-down into self-contained tasks.
Tasks are represented as cards on a board.
Cards are arranged to show their status.
Issues can be added to project boards and labelled.
Project boards can show the priority of their tasks.
Forks are copies of entire repositories that can be synced up with the original.
|
|
Release Management
|
Releases are stable versions of the code.
Zenodo can automatically generate DOIs for releases.
Software licenses can restrict what others can do with your code.
|
|
Writing Sustainable Code
|
Always assume that someone else will read your code at a later date, including yourself.
Rename variables and functions to add context to make your code more readable.
Add comments to explain why something was done in a certain way if not obvious.
Don’t add comments that just restate what code clearly already does.
Use docstrings at the start of functions and files to explain their behaviour and input/output parameters.
|
|
Managing a Mini-Project
|
Problems with code and documentation can be tracked as issues.
Issues can be managed on a project board.
Issues can be fixed using the feature-branch workflow.
Stable versions of the code can be published as releases.
|
|
Survey
|
|
{:auto_ids}
key word 1
: explanation 1
key word 2
: explanation 2