Skip to content
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

src: refactor code to remove duplicate logic #34553

Closed
wants to merge 1 commit into from

Conversation

yashLadha
Copy link
Contributor

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

@nodejs-github-bot nodejs-github-bot added the c++ Issues and PRs that require attention from people who are familiar with C++. label Jul 29, 2020
@mscdex
Copy link
Contributor

mscdex commented Jul 29, 2020

What do you mean by "library name" ?

@yashLadha
Copy link
Contributor Author

@mscdex array is part of default library provided by C++ http://www.cplusplus.com/reference/array/array/. When I first read the lines I thought why are we saving it in the default library keyword. This is done on the lines we won't name a variablevector.

@addaleax
Copy link
Member

I don’t see any particular reason to avoid the names of standard library classes. We’re never importing items from the std namespace with using, so there’s no chance for conflicts, either.

@yashLadha
Copy link
Contributor Author

yashLadha commented Jul 30, 2020

@addaleax Agree with you but as a convention should we be using keyword names as an identifier? I wrote the patch because if someone reads it they might think why we are using this variable name when it is a keyword defined in one the libraries provided. As we avoid using list as an identifier and give it a meaningful name this is done on the same lines. I don't see any issues with that but open to thoughts around this 😄

@joyeecheung
Copy link
Member

I'd prefer readability over potential keyword conflicts as well - especially considering the std namespace can be extended as C++ grows and keywords like list queue map set are already there. If anything, renaming array to something even more descriptive would be nice, like fields_array or typed_array here (I don't know how to name it in a way that's succinct enough while saying "this is a float64 array whose values will be read from the JS land later" to be honest so take my suggestion with a grain of salt)

@yashLadha
Copy link
Contributor Author

@joyeecheung Agree with you but my intention behind the changes is similar to usage of ab for arrayBuffer however your suggestion seems valid and the naming should be much more verbose in its meaning. Any suggestion or best practice for native code which we follow in the nodejs community?

@joyeecheung
Copy link
Member

joyeecheung commented Aug 5, 2020

@yashLadha I don't think there's any particular convention in native code variable naming, it's just my personal opinion that verbose names are better than names like ab (as one would have to see them a few times in the code base before understanding what they stand for, which makes it more difficult for new-comers to get started with the code base)

@yashLadha yashLadha changed the title src: rename variable to not use library name src: refactor code to remove duplicate logic Aug 6, 2020
@yashLadha
Copy link
Contributor Author

@joyeecheung @addaleax when I looked in the complete file itself found that this logic is being duplicated at several places, so converted the logic to use a single inline function so that code doesn't get duplicated.

@yashLadha
Copy link
Contributor Author

Also no performance degradation as well

                                 confidence improvement accuracy (*)   (**)  (***)
 process/memoryUsage.js n=100000        ***      4.51 %       ±0.90% ±1.19% ±1.52%

Be aware that when doing many comparisons the risk of a false-positive
result increases. In this case there are 1 comparisons, you can thus
expect the following amount of false-positive results:
  0.05 false positives, when considering a   5% risk acceptance (*, **, ***),
  0.01 false positives, when considering a   1% risk acceptance (**, ***),
  0.00 false positives, when considering a 0.1% risk acceptance (***)

Copy link
Member

@addaleax addaleax left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are the unrelated formatting changes here done by clang-format?

@yashLadha
Copy link
Contributor Author

Yes @addaleax linter did that.

@@ -89,6 +89,14 @@ static void Chdir(const FunctionCallbackInfo<Value>& args) {
}
}

inline Local<ArrayBuffer> get_fields_array_buffer(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would be better to name it like get_fields_array_buffer_from_first_argument, or accept an argument specifying the index of the argument array, otherwise this new convention makes the code less easier to grok IMO.

Copy link
Member

@tniessen tniessen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Lots of unrelated whitespace changes.

args.GetReturnValue().Set(cwd);
}

static void Kill(const FunctionCallbackInfo<Value>& args) {
Environment* env = Environment::GetCurrent(args);
Local<Context> context = env->context();

if (args.Length() != 2)
return env->ThrowError("Bad argument.");
if (args.Length() != 2) return env->ThrowError("Bad argument.");
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want these kind of changes?

Copy link
Contributor Author

@yashLadha yashLadha Sep 5, 2020

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was done by the clang-formatter 😅 not intentional

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you try reformatting the code and make sure you set CLANG_FORMAT_START to where this branch branches off from the master, so that it does not format irrelevant changes? For example since this PR only contains 3 commits you can also try CLANG_FORMAT_START=HEAD~3 make format-cpp

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@joyeecheung Output from the command

❯ CLANG_FORMAT_START=HEAD~3 make format-cpp
Formatting C++ diff from HEAD~3..
clang-format did not modify any files

I think what i can do is basically reset to master and do the changes only and do not format the code. In that way those unnecessary changes won't be there.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Removed the formatting changes.

We were fetching the buffer from the float array to send out the
response in js land, however that logic is being duplicated in
node_process.h. Now they will be using an inline to fetch the array
buffers and making it more generic.
@aduh95 aduh95 added author ready PRs that have at least one approval, no pending requests for changes, and a CI started. review wanted PRs that need reviews. request-ci Add this label to start a Jenkins CI on a PR. labels Nov 8, 2020
@github-actions github-actions bot removed the request-ci Add this label to start a Jenkins CI on a PR. label Nov 10, 2020
@nodejs-github-bot
Copy link
Collaborator

@aduh95 aduh95 added the commit-queue Add this label to land a pull request using GitHub Actions. label Nov 13, 2020
@github-actions github-actions bot removed the commit-queue Add this label to land a pull request using GitHub Actions. label Nov 13, 2020
@github-actions
Copy link
Contributor

Landed in 4b0308a...8656ab4

nodejs-github-bot pushed a commit that referenced this pull request Nov 13, 2020
We were fetching the buffer from the float array to send out the
response in js land, however that logic is being duplicated in
node_process.h. Now they will be using an inline to fetch the array
buffers and making it more generic.

PR-URL: #34553
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
@github-actions github-actions bot closed this Nov 13, 2020
codebytere pushed a commit that referenced this pull request Nov 22, 2020
We were fetching the buffer from the float array to send out the
response in js land, however that logic is being duplicated in
node_process.h. Now they will be using an inline to fetch the array
buffers and making it more generic.

PR-URL: #34553
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
@codebytere codebytere mentioned this pull request Nov 22, 2020
BethGriggs pushed a commit that referenced this pull request Dec 9, 2020
We were fetching the buffer from the float array to send out the
response in js land, however that logic is being duplicated in
node_process.h. Now they will be using an inline to fetch the array
buffers and making it more generic.

PR-URL: #34553
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
BethGriggs pushed a commit that referenced this pull request Dec 10, 2020
We were fetching the buffer from the float array to send out the
response in js land, however that logic is being duplicated in
node_process.h. Now they will be using an inline to fetch the array
buffers and making it more generic.

PR-URL: #34553
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
@BethGriggs BethGriggs mentioned this pull request Dec 10, 2020
BethGriggs pushed a commit that referenced this pull request Dec 15, 2020
We were fetching the buffer from the float array to send out the
response in js land, however that logic is being duplicated in
node_process.h. Now they will be using an inline to fetch the array
buffers and making it more generic.

PR-URL: #34553
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: Joyee Cheung <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. c++ Issues and PRs that require attention from people who are familiar with C++. review wanted PRs that need reviews.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants