M2 r cleanup

[kellijohnson-NOAA]

What is the feature?

@MOshima-PIFSC and @kellijohnson-NOAA worked on cleaning up the R code, which turned into decisions about what functions actually needed to be kept. Then, subsequent clean up of what was left.

• General clean up of all files in /R/ folder and associated tests and vignettes.
• Attempt to adhere to tidyverse style guide for R code, e.g., snake_case.
• More consistent formatting of roxygen tags.
• Removal of unused functions.
• After removing unused function, it appeared that usethis was no longer needed. We tested this in a branch and all tests passed so it the movement of usethis to Suggests is also included in this PR.

Close #567 Close #590 Close #588 Close #564 See a more detailed list of changes that were attempted to include in this PR in #567.

How have you implemented the solution?

Does the PR impact any other area of the project?

Input

There is an associated issue in the case studies about removing the use of FIMSFrameAge and just using FIMSFrame that @iantaylor-NOAA is in charge of and will be implementing once this PR is approved. @iantaylor-NOAA note, we also changed to n_years, n_ages, weight_at_age, etc. for object names such that there are no abbreviations and everything is snake case.

Output

NA

How to test this change

Developer pre-PR checklist

• [x] I relied on GitHub actions to :test_tube: things for me while I sat on the :couch_and_lamp:.

@jbigman-NOAA I assigned you as a reviewer because these changes are rather benign and more about general formatting and I thought it might help you jump into the code. Also, I am excited for a fresh perspective/thoughts about the R code in FIMS. Feel free to let me know if you are not interested or do not have time to review this PR.

[github-actions[bot]]

Instructions for code reviewer

Hello reviewer, thanks for taking the time to review this PR!

• Please use this checklist during your review, checking off items that you have verified are complete!
• For PRs that don't make changes to code (e.g., changes to README.md or Github actions workflows), feel free to skip over items on the checklist that are not relevant. Remember it is still important to do a thorough review.
• Then, comment on the pull request with your review indicating where you have questions or changes need to be made before merging.
• Remember to review every line of code you’ve been asked to review, look at the context, make sure you’re improving code health, and compliment developers on good things that they do.
• PR reviews are a great way to learn, so feel free to share your tips and tricks. However, for optional changes (i.e., not required for merging), please include nit: (for nitpicking) before making the suggestion. For example, nit: I prefer using a data.frame() instead of a matrix because...
• Engage with the developer when they respond to comments and check off additional boxes as they become complete so the PR can be merged in when all the tasks are fulfilled. Make it clear when this has been reached by commenting on the PR with something like This PR is now ready to be merged, no changes needed.

Checklist

• [ ] The PR is requested to be merged into the appropriate branch (typically main)
• [ ] The code is well-designed.
• [ ] The functionality is good for the users of the code.
• [ ] Any User Interface changes are sensible and look good.
• [ ] The code isn’t more complex than it needs to be.
• [ ] Code coverage remains high, indicating the new code is tested.
• [ ] The developer used clear names for everything.
• [ ] Comments are clear and useful, and mostly explain why instead of what.
• [ ] Code is appropriately documented (doxygen and roxygen).

[kellijohnson-NOAA]

@Bai-Li-NOAA I am thinking that we should squash all of these commits into a single commit before we merge it into main. What are your thoughts? I can do this and force push or we can just use the squash and merge button if you agree.

[Bai-Li-NOAA]

@kellijohnson-NOAA Good idea! It would be great if you can do it and force push. Thank you!

[kellijohnson-NOAA]

Okay @Bai-Li-NOAA it is now a single commit that can be merged in once the tests are passing. Who does the merge, the reviewer or the committer?

[Bai-Li-NOAA]

@kellijohnson-NOAA. The committer merges the changes.