Revise R codes based on Wickham book

[xiangzhu]

Below is a check list of guidelines on files in R/ from Wickham's package book: http://r-pkgs.had.co.nz/r.html

• Two extremes are bad: don’t put all functions into one file and don’t put each function into its own separate file.
• File names should be meaningful and end in .R.
• Avoid capitalisation problems by never using filenames that differ only in capitalisation.
• You don’t have to use my style, but I strongly recommend that you use a consistent style and you document it.
• If you’re working on someone else’s code, don’t impose your own style. Instead, read their style documentation and follow it as closely as possible.
• Variable and function names should be lowercase. Use an underscore _ to separate words within a name.
• Generally, variable names should be nouns and function names should be verbs.
• Where possible, avoid using names of existing functions and variables.
• Format suggestions on spacing , curly braces, line lengths, assignment, and commenting.
• Never run code at the top-level of a package: package code should only create objects, mostly functions.
• Don’t use library() or require(). Use the DESCRIPTION to specify your package’s requirements.
• Never use source() to load code from a file. Rely on devtools::load_all() which automatically sources all files in R/.
• Clean up after yourself with on.exit(): options(), par() and setwd()
• Isolate creating plots and printing output to the console in functions that only produce output.
• Use .onAttach() for startup message.
• To display startup messages, always use packageStartupMessage(), and not message().
• To set custom options for your package with options().
• If you use .onLoad(), consider using .onUnload() to clean up any side effects.
• If you’re planning on submitting your package to CRAN, you must use only ASCII characters in your .R files.
• The easiest way to use the special unicode escape "\u1234" format is to use stringi::stri_escape_unicode().

[pcarbo]

Those rules all sound reasonable to me, except: "Variable and function names should be lowercase. Use an underscore _ to separate words within a name." That's okay if you take that approach, but isn't necessary.

[xiangzhu]

@pcarbo Thanks! I think the most important part is being "consistent", especially working with others; i find the following two points from Wickham really helpful:

You don’t have to use my style, but I strongly recommend that you use a consistent style and you document it.
If you’re working on someone else’s code, don’t impose your own style. Instead, read their style documentation and follow it as closely as possible.

in my case i ll need to study Nick's existing style and try to be consistent