Loading functions from packages!

[alketh]

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.

[kellijohnson-NOAA]

@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.

[kellijohnson-NOAA]

@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.

[kellijohnson-NOAA]

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 ::

[slucey]

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 [email protected]
wrote:

Closed #17 #17.

—
Reply to this email directly or view it on GitHub
#17 (comment).

[kellijohnson-NOAA]

when you run devtools::check() you will receive warnings for both subsetting using data.table functions or if you use the subset function.