-
Notifications
You must be signed in to change notification settings - Fork 301
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
DAOS-623 client: allow variable declaration in loop #15428
base: master
Are you sure you want to change the base?
Conversation
Ticket title is 'Generic ticket for minor code cleanup and improvement' |
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.
It might be better to have a ticket number, I thought there is a MISC ticket for such PRs. @jolivier23
there is DAOS-623 |
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.
it would appear you don't need to change anything in clang-format. It must not care with current settings.
@wangshilong This PR is just for reference purpose so that I can collect community's feedback. I will certainly add a daos ticket once we decide to move it forward. Thanks for calling it out. |
@jolivier23 I don;t think this CI test (continuous-integration/jenkins/pr-head) would pass, I have tried 3 times but no luck. What would be your suggestion for the next step? |
There was a network issue when the build was starting, I've retriggerd it. |
Ideally, we should get a review from @daos-stack/client-api-owners before merging. |
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.
i do not get the purpose of doing these changes on just this file. this screws up git blame.
we probably have many other files that do not have clang format and i will request we don't do such changes for now unless we make a discussion to address this everywhere.
|
||
rc = dc_obj_get_grp_size(oh, &grp_size); | ||
if (rc) | ||
D_GOTO(out, rc); | ||
|
||
for (i = 0; i < layout->ol_nr; i++) { | ||
for (uint32_t i = 0; i < layout->ol_nr; i++) { |
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 not our coding style
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.
We don't have much code that looks like this but keeping the scope of variables as small as possible is something that is explicitly stated in our style guide and it's something that's generally considered best-practice across the industry. I know I've fixed at least one bug in our codebase where a loop variable was misused later in the function.
Changing existing code is laborious and time consuming, plus there are the issues it causes with glt blame and patches across branches etc but I that doesn't change the fact this style would be safer, more concise and preferable overall.
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.
i do not disagree. but we are not going to go on and change every part of the code to do this.
we are just going to cause more disruptions to ongoing prs, feature branches that is not going to give that much gain.
so i will approve the change for this file, because i know there is not much work going on in the object api area. @jxiong but please refrain from pushing such a change more broadly before discussing this more in developer channels and/or gatekeeping channels.
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.
@mchaarawi are you in the community slack channel? My understanding is this PR was created to support a discussion there.
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.
I am. this is not a community question though. this is developer specific topic.
I agree with you that we should not make PRs for this change only. This is just to make an example of such change. The PR description gives a clearer explanation on this. The goal is sort of to announce that this is a preferred way of defining loop variables. |
i think step 1 would be to revert all the clang format changes in the file. you should not format code that you did not touch. I am not ready to loose git blame information on all files :-) for the loop variable declaration, this is not something we discussed or adopted, so we cannot force it on everyone without a discussion in gatekeeping at least. |
That's absolutely reasonable. I don't have any background on this topic but it seems like we have a clang-format in place but it's not actually in use. (I have dev config that clang-format will be invoked automatically on file save). I will revert the clang-format change and resubmit. |
Change-Id: I8c6b78f95b3737f604ac87b4d16636202074c47b
4bc1807
Test stage NLT on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-15428/6/testReport/ |
@jolivier23 @ashleypittman can anyone of you please restart the CI for me? Thanks |
This PR tries to enable variable declaration in loop from C99 standard. This will not make coding easier, but will also make the code less error-prone by limiting the scope of looping variables.
The Linux kernel adopts C99 for this exact same reason.
NB: I only updated the variable in the for loops. It seems like this file hasn't been changed since new clang-format is used. Maybe I picked a wrong file to start with ;-)
Before requesting gatekeeper:
Features:
(orTest-tag*
) commit pragma was used or there is a reason documented that there are no appropriate tags for this PR.Gatekeeper: