[Wishlist] a 'PackageDevelopment' Task View

Sun, Jul 27, 2014 9:23 AM

On 27/07/14 - 08:42, Spencer Graves wrote:

On 7/27/2014 7:46 AM, Luca Braglia wrote:

I'm starting to think I'd like to keep the "Source Code" section
separated from the "Documentation" section ...  eg ideally the
macro topics could be in this order

1 - Creation
2 - Source Code
3 - Documentation
4 - Tools and services (was "Automation")

Furthermore IMHO a granular sub-topic structure is a plus (eg
few packages for a distinct/well-focused task is no problem,
maybe a resource ... )

An updated temp TOC (integrating your ideas, and some new
packages listed) could be

==============================================================

1 - Creation


  o Creating R packages - utils::package.skeleton, pkgKitten,
    Rcpp::Rcpp.package.skeleton


2 - Source code


  o Foreign languages interfaces - base R support for that,
    inline, Rcpp , Rcpp11, rJava

  o Debugging - base::debug utils::recover and friends

  o Code analysis - codetools

  o Profiling - utils::Rprof, aprof, profr, proftools

  o Benchmarking - base::system.time, microbenchmarking, rbenchmark

  o Unit testing - RUnit, svUnit, testthat


3 - Documentation


  o Writing Package Documentation (functions, data sets, classes
    and methods, packages) - roxygen2

  o Writing Vignettes - Sweave, knitr

  o Spell checking - tools::aspell_package_* functions
4 - Tools and services


  o Editors (supporting package development)
  o IDEs (supporting package development)

  o Makefiles

  o Revision control (most common in the R community):
    subversion, git

  o Hosting services (most common in the R community):
    r-forge, github


==============================================================


      I've heard claims that people who write documentation with unit tests
first tend to get better code faster than people who write the code first
and documentation (and maybe examples and unit tests) later.  I've heard
there is research behind this.  However, I'm not sure where to find it.
Others may be able to suggest publications that support or refute this
claim.


      In any event, I tend to create (a) documentation first, including (b)
unit tests in the examples section, before (c) writing code.  When I started
writing R packages following this model, I felt my software development
productivity increased by a factor of 5 or so.

Hi Spencer,

I'm trying that way of developing too (test before code), but
the numbering in my previous mail are not meant to be suggestion
for development process/flow steps (apologies for that, it was
only a way to alternate lists (numbers for sections, bullets for
tasks), no numbering is really going to be included in the task
view).

The proposed TOC was compiled in a way that (to me) eases finding which
packages are available, given what are you working on (source code
or documentation) and the specific task you need to accomplish.

Best,
  Luca

[Wishlist] a 'PackageDevelopment' Task View

Thread (11 messages)