-
Notifications
You must be signed in to change notification settings - Fork 34
Spec inconsistency around trace/location/other_locations (or maybe I'm just confused) #56
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
Comments
Hi Stephan, Thanks for your question! The location object usually looks like the examples given here:
The part you noted about Historically, it's been used with our duplication engine to reference the locations of similar code. Going to go ahead and open a PR to clarify. Thanks! |
@ABaldwinHunter Thank you 😃 |
* Clarify usage of other_locations key Addresses #56
It appears that codeclimate#20 intended to remove `other_locations` as superseded by `trace`, but it left the old entry (only) in the example JSON object. An expanded section describing `other_locations` was put back in codeclimate#57, that issue thread asserts that it is still valid and in use by Code Climate's duplication engine. These two fields certainly seem functionally redundant, hence codeclimate#56. Under assumption that both are used/accepted in implementations of the current version of the spec, this change restores presence of both in the reference but proposes deprecating `other_locations` and hence de-emphasizes its documentation.
Issues claims that an example output would look like this:
while the text below explains
trace
(which isn't part of the JSON blob):Further down we find an explanation of the
location
key, that's explaining that (I've highlighted what I'm confused about):What is correct, where does
other_locations
go? 😃Thanks,
Stephan
The text was updated successfully, but these errors were encountered: