The interface of a function describes how it interfaces with the world, independent of its internal implementation.
Chapter 6: All inputs to a function should be explicit arguments. Avoid functions that suprise the user by returning different results when the inputs look the same.
Chapter 7: Required arguments should come before optional arguments.
Chapter 8: Make arguments as orthogonal as possible. Avoid complex interdependencies.
220.127.116.11 Default values
Chapter 10: the absence of a default value should indicate that an argument is required; the presence of a default value should indicate that an argument is optional.
Chapter 12: If a details argument can take one of a fixed set of possible strings, record them in the default value and use
rlang::arg_match()inside the function.
Chapter 13: Default values should return the same answer when set directly.
Chapter 14: Default values should be short. If you have a complex calculation, either use
NULLor an exported function.
Chapter 15: If a default value is particularly important, as has non-trivial calculation, let the user know what it is.
Chapter 16: Use
getOption()to allow the user to set default values.
...should be placed between the data and details arguments.
Chapter 19: don’t use
...just to save the user from typing
c()(unless the function is purely for data structure creation).
Chapter 20: carefully consider if all other arguments need a
.prefix in order to reduce the chance of spurious matches.
Chapter 21: when using
...with S3 methods, or passing on to other functions that silently ignore mismatches, check that all inputs in
- Chapter 26: functions called primarily for their side-effects should invisibly return a useful value.