-
Notifications
You must be signed in to change notification settings - Fork 14
Style Guide
This document outlines some general guidelines for maintaining consistency in coding style, introduction of breaking changes, documentation, and overall design within aqp
. We should adhere to these suggestions to the extent that the they are helpful; none of us have the time to constantly nit-pick each other's work.
As we move forward, we should all strive to keep the main branch reserved for working, documented, and well-tested code.
Please be considerate when making suggestions for major changes to other's code, put major change suggestions into an alternate branch, and propose via pull request.
Dependencies should be kept to a minimum as we move forward, with the gradual replacement of plyr
and reshape
functionality replaced with data.table
.
See #140 for active discussion.
Coordination via PR (review?) is ideal (required?).
Commits should pass:
- tests OK
devtools::test()
-
R CMD CHECK --as-cran
ordevtools::check()
- PR?
Aspirations for now:
- optimize for intuition ("estimate a thing") and accurate code-completion (
estimate...
) vs. pure style adherance - relatively "uniform" syntax that reflects a cohesive, well-thought out package
- minimal number of keystrokes, while still providing essential context as to what a function does
- function names should include verbs -- they "do" something
- arguments (names) that refer to the same data for similar functions should do similar things
- some overlap of functionality is inevitable, but should be minimized and well justified
Package, functions, citations, documentation.