-
Notifications
You must be signed in to change notification settings - Fork 600
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
RuboCop: address some AbcSize issues #1849
RuboCop: address some AbcSize issues #1849
Conversation
Address some Metrics/AbcSize issues to get our maximum ABC size down closer towards a reasonable value
after refactoring to use 2 methods, the JS to inject needs to be passed to the second method. also the headers aren't used, so grab that var as `_headers`.
end | ||
end | ||
|
||
def establish_fire_everies(data_harvest) |
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.
fun method name lol everies
"#{e.class} - #{e.message}") | ||
end | ||
|
||
def install_dependency_detection |
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.
Love turning that comment into a method!
# Only scan the first 50k (roughly) then give up. | ||
beginning_of_source = source[0..SCAN_LIMIT] | ||
meta_tag_positions = find_meta_tag_positions(beginning_of_source) | ||
if body_start = find_body_start(beginning_of_source) | ||
if insertion_index = find_insertion_index(meta_tag_positions, beginning_of_source, body_start) | ||
source = source_injection(source, insertion_index, js_to_inject) | ||
else | ||
NewRelic::Agent.logger.debug("Skipping RUM instrumentation. Could not properly determine location to inject script.") | ||
NewRelic::Agent.logger.debug('Skipping RUM instrumentation. Could not properly determine location to ' \ | ||
'inject script.') |
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.
Why add\
in the debug message?
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.
Ah, so while I was fixing the AbcSize
issue I decided to also address another RuboCop issue with this code block to do with line length. By using backslashes, I just broke the super long debug text up into 120 column chunks.
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.
Oh just a length thing! Cool thank you
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 for taking care of this! I have a few suggestions/comments.
Did you happen to check SimpleCov for the updated files?
I ask because I think I may have forgotten last time I worked on a ticket like this and accidentally created a bug.
def establish_interval_transmissions | ||
@event_loop.on(interval_for(TRANSACTION_EVENT_DATA)) do | ||
transmit_analytic_event_data | ||
end | ||
@event_loop.on(interval_for(CUSTOM_EVENT_DATA)) do | ||
transmit_custom_event_data | ||
end | ||
@event_loop.on(interval_for(ERROR_EVENT_DATA)) do | ||
transmit_error_event_data | ||
end | ||
@event_loop.on(interval_for(SPAN_EVENT_DATA)) do | ||
transmit_span_event_data | ||
end | ||
@event_loop.on(interval_for(LOG_EVENT_DATA)) do | ||
transmit_log_event_data | ||
end |
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 still feels like a decent amount of duplication. Would it work to put tbe *_EVENT_DATA constants into an array and loop through them?
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.
The short answer for why I didn't do so is that I'm trying to very tightly scope this PR's changes to RuboCop related things. I brought in changes in line length and quotes because there are cops for those things, but I didn't want to do any refactoring to the code beyond that.
For a summary of a longer answer, that thought did come to mind in this section of the code but each constant is mapped to a different method call and the names don't all follow a common convention. For example: TRANSACTION_EVENT_DATA
maps to transmit_analytic_event_data
which breaks the pattern of transmit_<CONSTANT.downcase>. I also did not want to dive into a deep understanding of the requirements of what needs to take place in the context of an event loops
doblock. It's possible that something like
send(methodize(CONSTANT)` wouldn't work the same way. So I stuck to just satisfying the cop.
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.
Yeah that makes sense to me. One thought I had is that in the future if we want to further refactor this we could put the constants into a hash that has the methods in it, that way we don't have to try to guess or interpolate what the method name is supposed to be.
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.
Nice! I totally agree with making tightly scoped changes. This is great as-is.
o.on('-l', '--license-key=KEY', String, | ||
'Specify the license key of the account for the app being deployed') { |l| @license_key = l } | ||
o.on('-c', '--changes', | ||
'Read in a change log from the standard input') { @changelog = STDIN.read } |
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 love seeing these single quotes.
Isn't there a built-in linter for changing double quotes to singles for areas without interpolation? I wonder if that might be worth turning on?
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.
You can tell RuboCop to insist on the use of single quotes for strings without interpolation or you can tell RuboCop to insist on double quotes everywhere. I believe RuboCop currently defaults to the first one of those, but there has been well reasoned arguments for the second approach as well.
I believe we are currently disabling that cop and allowing any kind of quotes at any time regardless of interpolation.
If the devs decide on a standard, we can update the RuboCop config accordingly. Until then, I've been operating with my personal preference of RuboCop defaults.
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.
For the record! I prefer single quotes. Double quotes alert me to interpolation, so I'd love to see this single quote cop enabled.
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.
My preference is also single quotes unless in interpolation, though it can get hairy if we have apostrophes in our strings.
stop passing an argument that is ultimately not used to a method
3666602
SimpleCov Report
|
def establish_interval_transmissions | ||
@event_loop.on(interval_for(TRANSACTION_EVENT_DATA)) do | ||
transmit_analytic_event_data | ||
end | ||
@event_loop.on(interval_for(CUSTOM_EVENT_DATA)) do | ||
transmit_custom_event_data | ||
end | ||
@event_loop.on(interval_for(ERROR_EVENT_DATA)) do | ||
transmit_error_event_data | ||
end | ||
@event_loop.on(interval_for(SPAN_EVENT_DATA)) do | ||
transmit_span_event_data | ||
end | ||
@event_loop.on(interval_for(LOG_EVENT_DATA)) do | ||
transmit_log_event_data | ||
end |
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.
Yeah that makes sense to me. One thought I had is that in the future if we want to further refactor this we could put the constants into a hash that has the methods in it, that way we don't have to try to guess or interpolate what the method name is supposed to be.
Address some Metrics/AbcSize issues to get our maximum ABC size down closer towards a reasonable value
helps with #1520