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 ______________________________________________ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
