Signature

Checklist

(bullet points are in order of appearance)

[ ] First line explains briefly what the function does
- [ ] change viability to 'reference counter'
[ ] Simple example or snippet how to use the function
- [ ] add example
[x] Longer description of function containing common use cases
[x] Description of functions reads nicely
[ ] @pre
- [x]
  Precondition
  key is a valid key
[ ] @post
- [x]
  Postcondition
  reference counter of the key is incremented by one
[ ] @invariant
- [x]
  Invariant
  key stays a valid key
[x] @param for every parameter
[x] @return / @retval
[ ] @since
- [ ] add
[x] @ingroup
[ ] @see
- [ ] add keyGetRef()
- [ ] add keyDecRef()

[ ] Abbreviations used in function names must be defined in the Glossary
- [ ] add inc to glossary
- [ ] add ref to glossary
[x] Function names should neither be too long, nor too short
[x] Function name should be clear and unambiguous
Abbreviations used in parameter names must be defined in the Glossary
[x] Parameter names should neither be too long, nor too short
[x] Parameter names should be clear and unambiguous

(only in PRs)

Symbol versioning is correct for breaking changes
ABI/API changes are forward-compatible (breaking backwards-compatibility to add additional symbols is fine)

Function parameters should use enum types instead of boolean types wherever sensible
[x] Wherever possible, function parameters should be const
[x] Wherever possible, return types should be const
[x] Functions should have the least amount of parameters feasible

[x] Function code is fully covered by tests
[ ] All possible error states are covered by tests
- [x] add test for null pointer
All possible enum values are covered by tests
[x] No inconsistencies between tests and documentation