-
Notifications
You must be signed in to change notification settings - Fork 15
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
codeCheck with less questions #71
Conversation
Codecov ReportAttention:
Additional details and impacted files@@ Coverage Diff @@
## master #71 +/- ##
==========================================
+ Coverage 34.88% 35.93% +1.05%
==========================================
Files 51 51
Lines 1694 1650 -44
==========================================
+ Hits 591 593 +2
+ Misses 1103 1057 -46 ☔ View full report in Codecov by Sentry. |
I have to admit that I don't understand the new syntax. What would happen if I choose "2: group" in the first question? In is unclear what "group" means here. In the second question I understand the question but I am not so sure if others not that familiar with it will understand it. In addition, I am skeptical that it is a good idea to have only a single question for all realization. I can imagine that in some cases the realizations are all basically the same in which case I understand why the aggregation to one question might be desirable, but in other cases the realizations will have very different implementations and the answer might be different on a per realization basis. Hence, I believe that merging the second case in one question is most likely not feasible / not a good idea. |
|
thanks for the explanations. Having thought about it a bit further I think we might even get rid of the first type of question completely: If an interface is removed and does not occur anymore anywhere in the module this is basically a clean up task which - to my understanding - comes with no risk. Hence, I think it would be fine if the function just removes these interfaces from not_used. For the second case (not addressing an existing interface in some realizations) the situation is different and the questionaire is meant as a safety check that not addressing the interface is indeed the intended behavior. |
In these two cases, the structure of the question is fine, I think. What other application do you have in mind where you would like to be asked on a per-realization basis? |
|
@tscheypidi: are you fine with just deleting variables from not_used.txt of all realizations without asking if the variable is not used (anymore) anywhere in this module? |
Yes |
Ok, I implemented it such. I keep the info, but don't ask anymore. Additionally, you are now asked why you want to omit it, and that is added into the Here is the result of replacing
|
fine for me, if JPD agrees it can be merged |
@tscheypidi, any comment / approval? |
I am not sure whether "omitted" is the right word in this case. I would think that something like "'pm_lab' has been removed as interface and has been deleted from all not_used.txt files of module 'carbonprice'!" might be easier to understand. Similarly, I could imagine that also the second formulation might lead to some confusions. To me something like the following feels more intuitive: In module 'carbonprice', 'vm_cesIO' is not addressed in those 1 realizations: NDC! Other than the wording the behavior looks good to me. |
|
Ok, I did as you suggested, @tscheypidi… |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
thanks
not_used.txt
" into one single questionnot_used.txt
once, not once per realization.In https://github.com/remindmodel/remind/blob/develop/modules/45_carbonprice/NPi/not_used.txt, replace
vm_co2eq
bypm_lab
.Run
invisible(gms::codeCheck(strict = TRUE, interactive = TRUE)
. I omitted start and end, but paste just the selection process:old:
new: