-
Notifications
You must be signed in to change notification settings - Fork 23
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
[WIP] Clang tidy fixes #26
base: master
Are you sure you want to change the base?
Conversation
…aced-init-list' -fix
…lt-member-init' -fix
…ing-return-type' -fix
…around-statements' -fix
…er-size-empty' -fix
…-member-functions-to-static' -fix
…null-pointer' -fix
…t-bool-conversion' -fix
…stent-declaration-parameter-name' -fix
…-declaration' -fix
…mber-function-const' -fix
…st-parameter' -fix
…nt-access-specifiers' -fix
…nt-member-init' -fix
…nt-string-init' -fix
…accessed-through-instance' -fix
…se-literal-suffix' -fix
…idening-of-multiplication-result' -fix
…nit-variables' -fix
…ro-type-member-init' -fix
We should definitely not apply fixes that break the build ;-) |
My wording:
|
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.
This is a really useful set of checks and improvements Josef. A couple of comments and probably a few to discuss.
Ok, I didn't realise you were still working on this at the same time as me. I'm trying desperately to avoid doing that, sorry. I'll go back through my list of comments and review your assessment. Please, hold off updating for a few hours to give me a chance to get through it. |
I hope this summary list below still lines up with the review comments above. If in doubt, the review comments were written later if that helps). Summary of responses. The review comments might site specifics etc but the main comments are here: - SFSF: discuss (or default to no): As mentioned in my review comment, clang-tidy didn't seem consistent in when it triggered on this. In principle, the check itself is ok.
SF: yes (and agree with your approach to the fix)
SF: yes
SF: Yes. Your notes make more sense than the changes clang-tidy provided LOL. Definitely keen for this to be a well written and reviewed fix!
SF: YES!
SF: yes: If these are a consequence of other changes making things static that weren't previously, then lets go with it. SF: yes SF: yes (my review comments danced around on this one but seems more in keeping with moving defaults to declarations. SF: yes SF: yes (as auto is now being used)
SF: yes
SF: yes
SF: yes
SF: yes (but agree the more meaningful name isn't always the one that has been suggested here. In most cases, the header is better which makes sense, peter always wrote interfaces first almost to completeness and then filled in the implementation. SF: no, (or perhaps discuss). In some instances the implicity bool makes sense isupper() reads nicely to humans. But boolean checks against zero make me queasy. On balance, no but happy to chat more.
SF: discuss: I like the idea of code review/improve. But I do think the current form is easier to read in terms of intent.
SF: yes SF: yes (a holdover from earlier times)
SF: yes but agree on the review. SF: yes
SF: yes. (My current day-job is on medical devices. Can confirm!) SF: no (my default is to leave it unless there is a benefit.)
SF: no (agreed wholeheartedly with your reasoning)
SF: discuss: Keen to understand the value. I may just be out-of-date on this one.
SF: yes SF: discuss: Not sure of the benefit here. Declaring without implementing (as already done) has exactly the same effect. I guess this is more explicit; is that th epoint? SF: yes SF: yes SF: Yes (see my comment in the review but really like this
SF: YES!
SF: yes SF: yes
SF: yes (only because it is the easiest way to get consistency :-) ) SF: yes SF: no - complexity for no obvious benefit (we aren't shifting megabytes around in any of these). Happy to be convinced otherwise. SF: yes. If we are going to make some of the other modernize fixes, this one may as well go in.
SF: yes.
SF: yes - but I'm nervous about cutting off folks on older platforms which was litterally the original usecase for SRecord. Chances are this worry is completely unfounded. My wording:
Adding:
|
Update: These were agreed to be not fixed:
So these messages are left, which can be autofixed (but may need manual changes or reviews, see comments above)
For the current state of unfixed messages see |
ATTENTION: this PR is not for a detailed review.
Please have a rough look at each commit (maybe just the first 2-3 changes), which kind of auto-fix makes sense.
I will post my conclusion hopefully within a day (I do not have time now).
When we decide on which fixes shall be applied, I will look into every change in detail.
Short summary up-front:
modernize-loop-convert
maybe needs loop variables renamed for claritymodernize-use-trailing-return-type
is weird, I would not apply it