visdat package

[njtierney]

Summary

• What does this package do? (explain in 50 words or less)

visdat visualises R data frames so that you can quickly identify data structure and data types. This makes it easier to "get a look at the data" and visually identify abnormalities with a dataset.

• Paste the full DESCRIPTION file inside a code block below.

Package: visdat
Title: Preliminary Visualisation of Data
Version: 0.0.5.9000
Authors@R: person("Nicholas", "Tierney", email = "nicholas.tierney@gmail.com", role = c("aut", "cre"))
Description: visdat makes it easy to visualise your whole dataset so that you
    can visually identify problems.
Depends:
    R (>= 3.2.2)
License: MIT + file LICENSE
LazyData: true
RoxygenNote: 5.0.1.9000
Imports:
    ggplot2,
    tidyr,
    dplyr,
    purrr,
    readr,
    plotly (>= 4.5.6),
    magrittr,
    stats
URL: https://njtierney.com/visdat
BugReports: https://github.com/njtierney/visdat/issues
Suggests:
    testthat,
    knitr,
    rmarkdown,
    vdiffr
VignetteBuilder: knitr

• URL for the package (the development repository, not a stylized html page)

https://github.com/njtierney/visdat

• Who is the target audience?

R users who want to explore their data, particularly when they first receive it.

• Are there other R packages that accomplish the same thing? If so, what is different about yours?

In terms of visualising missing data as a heatmap, there are a few other packages that have worked on this. The mi package used to have a visualisation method for missing data, missing.pattern.plot - however this is no longer present in the latest versions. The Amelia package has missmap, but the default requires some more work to make the final output easier to read.

The VIM package provides visualisations for missing data, for example, the aggr function provides a histogram of the missingness present in each variable.

In terms of visualising the types of data in a dataset, the wakefield package provides the table_heat function for visualising column data types.

But what makes visdat different?

visdat adheres to the principle that R packages should try to do one thing, it is a simple package that specialises in visualisation of data frames. Amelia and mi focus on multiple imputation and missing data methods. VIM focusses on visualising missingness and imputation in data, and the wakefield package focusses on creating random, reproducible data.

The functionality in visualising missing data for these packages is not the main focus, and so I argue that because visdat is purely about visualising dataframes, it gives it greater scope to work on just one thing.

Requirements

Confirm each of the following by checking the box. This package:

• does not violate the Terms of Service of any service it interacts with.
• has a CRAN and OSI accepted license.
• contains a README with instructions for installing the development version.
• includes documentation with examples for all functions.
• contains a vignette with examples of its essential functions and uses.
• has a test suite.
• has continuous integration with Travis CI and/or another service.

Publication options

• Do you intend for this package to go on CRAN?
• Do you wish to automatically submit to the Journal of Open Source Software? If so:
  • The package contains a paper.md with a high-level description.
  • The package is deposited in a long-term repository with the DOI:

Detail

• Does R CMD check (or devtools::check()) succeed? Paste and describe any errors or warnings:

It succeeds, but there are some notes.

checking R code for possible problems ... NOTE
vis_guess: no visible binding for global variable ‘valueGuess’
Undefined global functions or variables:
  valueGuess

• Does the package conform to rOpenSci packaging guidelines? Please describe any exceptions:

It does not yet have an rOpenSci footer image

I have not set up pre-commit hooks to ensure that README.md is always newer than README.Rmd, as I'm not sure what devtools::use_git_hook does?

I have not added #' @noRd to internal functions as I think it is still useful to have them documented, but I can change this if need be.

• If this is a resubmission following rejection, please explain the change in circumstances:

• If possible, please provide recommendations of reviewers - those with experience with similar packages and/or likely users of your package - and their GitHub user names:

• Maëlle Salmon (@masalmon)

• Jenny Bryan (@jennybc)

• Andrew MacDonald (@aammd)

[seaaan]

I don't know if this is allowed, but I volunteer to review this package. I've been wanting to give back to rOpenSci since I had a package reviewed.

[noamross]

That's fine @seaaan, I'll assign once I get through editor checks. Could you fill out the form at http://ropensci.org/onboarding/? We've started using that to help keep track of reviewers' various expertises.

[seaaan]

@noamross done!

…

On Wed, Jan 4, 2017 at 7:13 AM, Noam Ross ***@***.***> wrote: That's fine @seaaan <https://github.com/seaaan>, I'll assign once I get through editor checks. Could you fill out the form at http://ropensci.org/ onboarding/? We've started using that to help keep track of reviewers' various expertises. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#87 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AKDNdTKLD7524o6M_Q8h0Xd4-GaZZCbnks5rO7cdgaJpZM4LaRc6> .

[noamross]

Editor checks:

• Fit: The package meets criteria for fit and overlap
• Automated tests: Package has a testing suite and is tested via Travis-CI or another CI service.
• License: The package has a CRAN or OSI accepted license
• Repository: The repository link resolves correctly
• Archive (JOSS only, may be post-review): The repository DOI resolves correctly
• Version (JOSS only, may be post-review): Does the release version given match the GitHub release (v1.0.0)?

---

Editor comments

Currently seeking additional reviewers. This package fits well into our visualization/reproducibility categories.

• I note that vignette building fails without a recent version of plotly. I suggest you set minimum version numbers for packages in your DESCRIPTION file.
• Below is goodpractice::gp() output, with some small things to be addressed. Test coverage is relatively low, which is understandable given the nature of the package, but I suggest you look into using the vdiffr testthat extension to create tests for expected visual output.

── GP visdat ─────────

It is good practice to

  ✖ write unit tests for all functions, and all package code in general. 12% of code lines are covered by test cases.

    R/compare_print.R:10:NA
    R/compare_print.R:11:NA
    R/compare_print.R:12:NA
    R/compare_print.R:13:NA
    R/fingerprint.R:11:NA
    ... and 287 more lines

  ✖ avoid long code lines, it is bad for readability. Also, many people prefer editor windows that are about 80 characters wide. Try make your lines shorter than 80 characters

    R/vis_compare.R:24:1
    R/vis_compare.R:27:1
    R/vis_compare.R:30:1
    R/vis_compare.R:33:1
    R/vis_dat.R:29:1
    ... and 3 more lines

  ✖ avoid 1:length(...), 1:nrow(...), 1:ncol(...), 1:NROW(...) and 1:NCOL(...) expressions. They are error prone and result 1:0 if the expression on the right hand side is zero. Use seq_len() or seq_along() instead.

    R/vis_compare.R:46:26
    R/vis_dat.R:50:26
    R/vis_guess.R:42:26
    R/vis_miss.R:43:24
    R/vis_miss.R:74:26

  ✖ fix this R CMD check NOTE: vis_guess: no visible binding for global variable ‘valueGuess’ 

---

Reviewers: @seaaan @batpigandme
Due date: 2017-01-30

[noamross]

Reviewers assigned: @seaaan @batpigandme

[njtierney]

Hi Everyone,

Thank you very much for this, this is great feedback, and a great process.

I'm not sure what my expected role here as submitter is but I just wanted to say that I agree with the feedback given, and have been looking for a good excuse to use vdiffr, so that's good. Thank you @noamross for your suggestions, and to @seaaan for volunteering.

I was also wondering if I am able to submit this paper to JOSS? I understand if this is too late to do so.

[noamross]

Fine to submit to JOSS. To do so, check off the the JOSS publication options above, and write a paper.md file per JOSS requirements. Let us know when you have so reviewers can do the whole review at once. You can save deposition in a repository for a DOI for after you have made changes post-review.

[noamross]

Oh, and the comments I put above, e.g., testing, can be addressed once all other reviews are in, too. If they were major I would have held up assigning reviewers until they were addressed.

[njtierney]

OK great, just working on the JOSS paper now, will hopefully have it done this evening.

Re your comments @noamross

I note that vignette building fails without a recent version of plotly. I suggest you set minimum version numbers for packages in your DESCRIPTION file.

DESCRIPTION file has been updated to reflect this here

Below is goodpractice::gp() output, with some small things to be addressed. Test coverage is relatively low, which is understandable given the nature of the package, but I suggest you look into using the vdiffr testthat extension to create tests for expected visual output.

Here is my updated output from goodpractice::gp()

── GP visdat ────────────────────────────────

It is good practice to

  ✖ write unit tests for all functions,
    and all package code in general. At
    least some lines are not covered in
    this package.

    R/vis_compare.R:33:NA
    R/vis_compare.R:34:NA

───────────────────────────────────────────── 

Test coverage is now at 99% using vdiffr. I think I have used vdiffr correctly, it looks like the main use is to check that the plot reliably produces the same output, and the test uses expect_doppelganger().

Thank you again for the feedback, I will let you know when I add the paper.md doc.