Feedback on Chapter 6: The package within

[jthomasmock]

I love this chapter! It feels like a more compact journey through the whole game from a realistic perspective. Bravo!

While I don't necessarily think it requires an additional section in this exact chapter, as a middling package dev I am looking for guidance in protecting against craft or novice useRs. It could be an example in the side-effects vein. Ultimately, I think it's worth a whole chapter somewhere 😄 .

IE what happens when the user passes a list() rather than a single df and how to write defensive code with checks/validators:

• stopifnot(), warning(), the checkmate, assertthat, assertivepackages, etc.
• Almost a variation of this: https://blog.r-hub.io/2022/03/10/input-checking/
• Some components of this are converted in testing chapter, but that feels very dev-focused as opposed to package writing that provides a delightful user experience.

I'm not sure if it's fully in scope for this chapter/section, but documenting design patterns for "defensive programming" and avoiding bad "code smells" in argument validation and function writing would be highly valuable!

When I teach about Package development, I spend the first half of the time on writing functions and providing basic validations and/or useful error messages/defense against unexpected inputs.

[jennybc]

I love this chapter! It feels like a more compact journey through the whole game from a realistic perspective. Bravo!

Thanks! I'm not particularly satisfied with this chapter, but I do think it's important. Hearing that you like it is much-needed encouragement that it's worth holding on to and improving.

The content you're describing sounds very much in the wheelhouse of what https://design.tidyverse.org aims to address.

I propose to close this issue here, but open the equivalent issue there.

[jennybc]

As previously discussed, closing in favor of tidyverse/design#141.