Closed alketh closed 8 years ago
@alketh this is great advice. I am going to go through the current functions and make sure this practice is being used and then I will make a note of it in #10 so that we do not forget. I have also started a best practices guide in the wiki.
@alketh can you make sure the %>%
thing is properly documented with @importsFrom
or however we should do it. I am not familiar with the pipes and where they come from otherwise I would.
@slucey can you make sure data.table
is documented everywhere it should be? Thanks.
Eventually I will be removing all references to data.table and arrayhelpers. These two functions make code reading by non users of those packages difficult and if using data.table the package is not CRAN compatible. Otherwise everyone is doing a good job using ::
I'm not sure what you mean that using data table will make the package not CRAN compatible. There are over 60 packages on CRAN that use data table already. I agree that it makes reading the code different but the package is super powerful and useful.
Sean
Sean M. Lucey Fisheries Biologist U. S. Dept. of Commerce/NOAA/NMFS Northeast Fisheries Science Center 166 Water Street, Woods Hole, MA 02543 508-495-2011 (voice) 508-495-2232 (fax)
On Fri, Dec 11, 2015 at 10:33 AM, Kelli Johnson notifications@github.com wrote:
Closed #17 https://github.com/r4atlantis/atlantisom/issues/17.
— Reply to this email directly or view it on GitHub https://github.com/r4atlantis/atlantisom/issues/17#event-489454902.
when you run devtools::check()
you will receive warnings for both subsetting using data.table
functions or if you use the subset
function.
we should always explicitly name the packages the functions origin from to minimize conflicts between package dependencies. E.g. instead of importing functions like "open.nc" use RNetCDF::open.nc instead.