Skip to content

Conversation

@bcsgh
Copy link
Contributor

@bcsgh bcsgh commented Feb 26, 2020

Identify the Bug

#177 (General code style issues)

Description of the Change

Rename some variable so that all this-> can be dropped, and do so.

this-> is almost always redundant.

Side Note: the cases where this required changing the name of local variable to not conflict with member variable is the reason that many style guides (e.g. https://google.github.io/styleguide/cppguide.html#Variable_Names) require different forms for those types of variables. It may be worth renaming all private member variables at some point.

Alternate Designs

n/a

Possible Drawbacks

none really.

Verification Process

Normal build process. CI build to follow

Release Notes

  • Code cleanup relating to this->.

@bcsgh bcsgh changed the title Rename some variable so that all this-> can be dropped, and do so. etr#179 Rename some variable so that all this-> can be dropped, and do so. Feb 26, 2020
@codecov-io
Copy link

codecov-io commented Feb 26, 2020

Codecov Report

Merging #180 into master will not change coverage.
The diff coverage is 94.38%.

Impacted file tree graph

@@           Coverage Diff           @@
##           master     #180   +/-   ##
=======================================
  Coverage   95.19%   95.19%           
=======================================
  Files          35       35           
  Lines        3140     3140           
=======================================
  Hits         2989     2989           
  Misses        151      151
Impacted Files Coverage Δ
src/http_response.cpp 85.71% <0%> (ø) ⬆️
src/httpserver/details/http_endpoint.hpp 100% <100%> (ø) ⬆️
src/httpserver/http_resource.hpp 33.33% <100%> (ø) ⬆️
src/httpserver/http_request.hpp 92.3% <100%> (ø) ⬆️
src/httpserver/deferred_response.hpp 100% <100%> (ø) ⬆️
src/details/http_endpoint.cpp 100% <100%> (ø) ⬆️
src/httpserver/http_response.hpp 80% <100%> (ø) ⬆️
src/http_utils.cpp 99.17% <100%> (ø) ⬆️
src/http_request.cpp 96.69% <100%> (ø) ⬆️
src/webserver.cpp 90.47% <84.61%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 3258a63...4c80b6b. Read the comment docs.

@bcsgh bcsgh marked this pull request as ready for review February 26, 2020 17:38
@bcsgh
Copy link
Contributor Author

bcsgh commented Feb 28, 2020

I think the failing coverage is another case of pre-existing conditions.

Copy link
Owner

@etr etr left a comment

Choose a reason for hiding this comment

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

Thanks a lot for removing redundancy. The only ones I'd prefer to leave the same are the explicit setters where I believe "this" gives us a more explicit sense of the fact that a property of the object is being changed. The rest looks good.

};

void http_request::set_method(const std::string& method)
void http_request::set_method(const std::string& method_src)
Copy link
Owner

Choose a reason for hiding this comment

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

I'd leave this specific one as is given that it is a setter method

void set_content(const std::string& content_src)
{
this->content = content.substr(0,content_size_limit);
content = content_src.substr(0,content_size_limit);
Copy link
Owner

Choose a reason for hiding this comment

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

as for the other setter I commented, I'd leave this one with "this" that I find more expressive in this case

void set_content_size_limit(size_t content_size_limit_src)
{
this->content_size_limit = content_size_limit;
content_size_limit = content_size_limit_src;
Copy link
Owner

Choose a reason for hiding this comment

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

same

void set_path(const std::string& path_src)
{
this->path = path;
path = path_src;
Copy link
Owner

Choose a reason for hiding this comment

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

same

void set_version(const std::string& version_src)
{
this->version = version;
version = version_src;
Copy link
Owner

Choose a reason for hiding this comment

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

same

* @param args The args key-value map to set for the request.
**/
void set_args(const std::map<std::string, std::string>& args)
void set_args(const std::map<std::string, std::string>& args_src)
Copy link
Owner

Choose a reason for hiding this comment

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

same

print_request_resource(std::stringstream* ss_src)
{
this->ss = ss;
ss = ss_src;
Copy link
Owner

Choose a reason for hiding this comment

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

same

print_response_resource(std::stringstream* ss_src)
{
this->ss = ss;
ss = ss_src;
Copy link
Owner

Choose a reason for hiding this comment

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

same

@bcsgh
Copy link
Contributor Author

bcsgh commented Feb 29, 2020

Regarding the setters; I fully agree with your intent, but I strongly disagree with your proposed means.

The intent of making it clear where a variable is coming from the object vs. somewhere else is rather desirable, but not just in setters; it is my opinion that that should be done universally.

As noted in the PR description, I'd suggest accomplishing that intent (universally) by making the form of member variable names distinct from locals. The create_webserver class already does this by prepending a _ to it's members and I'd suggest there is more general utility in applying that pattern[1] globally than in adding this-> on a case-by-cases basis.

If that is going to be the done, then making that transformation as a follow-on PR would be the preferred next step[2] and dropping these this-> now would be the proper action here.

All that said, that's my opinion, and this is your code. So I'll just make my case and let you decide.

[1]: I personally prefer trailing _ as is the google style, but that's even more a matter of taste than tabs vs. spaces.
[2]: that is rendered somewhat more complex by the presence of protected members variables that may be used by sub-classes outside this repo. However, that (having protected data members) is a bit of technical debt that is likely better fixed now than later (https://ericlippert.com/2020/02/27/hundred-year-mistakes/). If you are interested, I could probably dig up a case for why member variable should basically never be protected (tl;dr; something along the lines of don't mix API and implementation).

@etr
Copy link
Owner

etr commented Feb 29, 2020

I appreciate the feedback but I'd stay with setters parameters matching the object internal one and "this" used. The general rule of thumb is that "this" is /almost/ always redundant. The setters are where /almost/ has value for me in that sentence. I agree with the rest of your CR though, as elsewhere, it is redundant.

create_webserver has been managed differently to allow for members to be named to match those in the webserver class.

On the protected members, sadly that has been poisoning this repo for a long time. Admittedly, they need better handling that I didn't have the time to do. Some of these things have been in the repo for quite a while as the project itself has been around for ~10 and has accumulated tech debt.

@etr
Copy link
Owner

etr commented Feb 29, 2020

Additional note that I think wasn't clear at all from my previous comment. I would be totally happy with a subsequent change to enforce the use of "_" in front of all class members (thus making "this" redundant for setters). In the context of this PR, I rather prefer having setters using "this" than having parameters with different names.

@etr etr merged commit a7b9b6a into etr:master Mar 1, 2020
@etr
Copy link
Owner

etr commented Mar 1, 2020

Everything merged. Thanks again for your support to the library.

@bcsgh bcsgh deleted the rm_this branch March 6, 2020 21:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants