insightsengineering / tern

Table, Listings, and Graphs (TLG) library for common outputs used in clinical trials
https://insightsengineering.github.io/tern/
Other
77 stars 21 forks source link

Adopting better standard for file names and related documentation files #623

Open Melkiades opened 2 years ago

Melkiades commented 2 years ago

I found that tern has some functions grouped together in an .R file, while they produce different documentation files. I think this is very confusing when you go from using a function (and its documentation) to accessing or modifying the source code. I propose here to reorganize these functions so as to have a source file per document file. Also, if not utils-files, the source files should be named as the documentation files. The advantages of this approach are beyond clarity. It is better suited to example correction and better for understanding changes in files when a PR is reviewed.

This issue would not break anything at all but as git-diff is file-based, I suggest solving this issue before other PRs, even incrementally if needed. Any feedback is welcome! @gogonzo @shajoezhu

gogonzo commented 2 years ago

Yup I agree and disagree. For example we have a classes for which we write methods. For example FilteredData has filtered_data_new, get_filter_states etc. If we had one file for the single doc-method we would probably end up with too many files. In case of utils which are related to some specific functionality I'd prefer to keep them in single file like grid-utils.R or color-utils.R (instead of all in utils.R).

Good example is dplyr/R/colwise.R https://github.com/tidyverse/dplyr/blob/main/R/colwise.R There are also other colwise like colwise-select.R etc.

So I prefer better grouping instead of having 1-to-1 match between .R and .Rd. But I don't insist as this could be a matter of preference

Melkiades commented 2 years ago

I agree with you. My main concern here is to have unrelated functions inside files that have different exported documentation. This can be problematic to read and modularize at the end. The issue also was opened as a general need for simplifying and splitting long files whenever the grouping is not well defined.

edelarua commented 2 years ago

Hi @Melkiades @gogonzo I've also been looking into this issue and I would suggest that for this specific issue we:

Introducing these changes for now will make some noticeable improvements to the current structure, and we can discuss more organizational changes in the future as we see a need for them so this task does not get too large.

Let me know if you have any thoughts on this. Thanks!

Melkiades commented 2 years ago

I think your proposal is great!!