Skip to content

Style Guide

Dylan Beaudette edited this page Feb 11, 2021 · 12 revisions

Overview

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.

Other People's 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

Dependencies should be kept to a minimum as we move forward, with the gradual replacement of plyr and reshape functionality replaced with data.table.

Code

See #140 for active discussion.

Committing to the master branch (GitHub)

Coordination via PR (review?) is ideal (required?).

Commits should pass:

  • tests OK devtools::test()
  • R CMD CHECK --as-cran or devtools::check()
  • PR?

Function Design

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

Documentation

Testing

CRAN Release Cycle

Authorship

Package, functions, citations, documentation.

Clone this wiki locally