-
Notifications
You must be signed in to change notification settings - Fork 73
Renaming #16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
A consistent name is a good idea. Can we simply use |
Ok yes, let us just use |
Reference: #146 (comment). |
So as stated in #146 (comment), should we use |
This includes documentation also obviously. |
Yes, we can keep the terms "parse data" and "nested parse data" for simplicity. The latter consists of multiple interlinked nests, this is the only new term. |
Reference: #132. |
Renaming of files
|
Do we need to change anything here, short of renaming the files as you suggested? |
Seems no, if we want to leave the rest ( |
|
Naming of data
At the moment, for the parse table returned by utils::getParseData and
processed through various functions, we use many different names in different
functions for essentially this (flat) table:
I think it would simplify things to just use one variable name throughout. I
suggest parse_data. We could use
parse_data_flt
for the flat version and andparse_data_nstd
for the nested version for situations where the processingdiffers.
Naming of functions
As far as I understand, the terminology around
ws
is more of a legacy thing, i.e. in the functionscompute_parse_data_flat_with_ws
oradd_ws_to_parse_data
since it is not really just white space information that is affected by these functions, but rather a bunch of preprocessing Hence, I would suggest to rename the latter topre_process_parse_data
and the former tocompute_parse_data_flt
for now.The text was updated successfully, but these errors were encountered: