Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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
Add and update Javadoc on realtime classes #5585
Add and update Javadoc on realtime classes #5585
Changes from 17 commits
0b8dfc6
2bb60a0
3f79a1d
7a0b56d
a0c18f4
710b678
3b94c8f
0cc8c40
873ceec
e3b5326
c23038e
79de961
9c342a6
94fea1d
a92917b
d5dbf79
50bd252
74430b0
31dc110
871c9c2
e0f74f1
0764267
97d99b0
f4a23d8
ce31c8e
c66d301
df3361f
File filter
Filter by extension
Conversations
Jump to
There are no files selected for viewing
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.
Java doc should not be added to private fields, but the get (or set) accessor.
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.
In this case, the private field can only be set via the constructor. The comment can be moved to the constructor but then for a maintainer working on the internals of this class to understand what the earlyStart field does, they'd need to find that it's set in the constructor, read the constructor javadoc, and confirm that the documented constructor parameter sets this field.
I get the idea of wanting the documentation concentrated on public methods, but I think it depends whether the documentation is intended for developers working on this code, or for developers making use of the code. In a case like this I'd be inclined to duplicate the documentation - maintenance can cross a line to being very tedious when the reader has to go searching for the meaning of every field.
Some DRY could be achieved by linking the private field Javadoc to the only place it's set, but this requires a verbose approach that is just as long as the comment explaining the purpose of the field, and much more fragile/full of irrelevant detail:
/** @see #SiriAlertsUpdateHandler(String, TransitModel, TransitAlertService, SiriFuzzyTripMatcher, Duration) */
I also find there's something non-generalizable about a convention of documenting on an accessor method because the relationship from fields to methods that mutate them is one-to-many. There's not one unambiguous place to put the documentation (on a setter, a factory method, one of several constructors?) but there is a single field they're all referencing.
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 moved it to an
@see
annotation on the constructor javadoc.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 strategy for handling IDs should be documented in a more visible place than on a private method. I also think we probably need to allow more than one strategy - so it should be extracted so it is pluggable. This is probably one of the main things we need to fix to more this from the Sandbox to the main code.
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.
From a maintenance perspective, this may be a good place to document the structure of the IDs because they are created during this mapping operation. Although I value DRY, the same concern exists here as other places above: increasing visibility of docs for people reusing/configuring the encapsulated code might make it hard for the maintainer to find those descriptions and use them to quickly understand the actions of this method.
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 have also put the information in the class-level Javadoc, and rephrased the information for the two contexts. Also included a note that FeedScopedId creation strategy should be pluggable or configurable as a condition for moving out of sandbox.
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.
There is no information here, then it is better to delete the comment.
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.
Some of the comments in this PR were tracking things I was not sure about, or queueing up to investigate. I didn't want to commit definitive statements or remove docs until I was sure of what I was seeing. In this case I think the Javadoc seemed so out of place that I was questioning my own interpretation. Maybe the code was just copied without changing the documentation. Looking at it again, these are clearly ET and not VM so I updated the comment.
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.
Consider pushing this into the JavaDoc on the update method.
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.
From a maintenance perspective, it can be very helpful to have an inline narrative of what a method is doing including some non-obvious details, without needing to read and piece together the details of each called method's own documentation. I generally added comments like this for details that tripped me up, which I thought could help future comprehension or refactoring.
I have moved the new detail about the behavior of the called method into that method's Javadoc, while keeping a one-line note here in the caller.
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 would guess this is used by the "Transmodel API", not SIRI - but have not looked into it. Note! APIs should work/be independent of data provider(s).
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.
What I meant here is that this class exists in two versions (SiriTripPatternCache and the non-SIRI TripPatternCache i.e. GTFS version) and the following field looks like an index that only exists on the SiriTripPatternCache. Indeed, maybe the SiriTripPatternCache is not really about SIRI but just an Entur fork of the TripPatternCache which happens to be Transmodel-oriented. However, I think this these TripPatternCache classes do exist primarily or only to track entities created in real time, and this may be effectively restricted to SIRI sources (it's not clear for the reader).
This further emphasizes the naming and code divergence problems we've discussed before: the name of the class gives the impression there's something SIRI-specific about it, and implies there's some reason tracking TripPatterns created in real time would be different for SIRI and GTFS-RT sources. But really this is probably just due to forking classes to accelerate development.
I will update this comment to make it a little more clear.