-
Notifications
You must be signed in to change notification settings - Fork 10.4k
Improve documentation RequestHeaders and ResponseHeaders #14971
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
Conversation
@anurse your favorite kind of PR 😄. |
/// <typeparam name="T">The type of the header. | ||
/// The given type must have a static TryParse method</typeparam> | ||
/// <param name="name">The name of the header to retrieve.</param> | ||
/// <returns>The value of the header</returns> |
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.
As a follow-up, we should either make another PR or add to this PR to add xml documentation for the rest of these properties.
Also, isn't there an analyzer that we can enable to check for all public apis that don't have xml docs?
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.
One small nit:
/// <returns>The value of the header</returns> | |
/// <returns>The value of the header.</returns> |
Also, isn't there an analyzer that we can enable to check for all public apis that don't have xml docs?
It's even better than that :). If we turn the right settings on we get a build warning (or error if we promote it to that). Some projects are using that now. We need to get "clean" before we can turn that on more broadly though.
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 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.
Generally looks good! Let's make all the methods consistent in how the docs are formatted. Once we've got that, I think we'll be good to go.
/// <typeparam name="T">The type of the header. | ||
/// The given type must have a static TryParse method</typeparam> | ||
/// <param name="name">The name of the header to retrieve.</param> | ||
/// <returns>The value of the header</returns> |
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.
One small nit:
/// <returns>The value of the header</returns> | |
/// <returns>The value of the header.</returns> |
Also, isn't there an analyzer that we can enable to check for all public apis that don't have xml docs?
It's even better than that :). If we turn the right settings on we get a build warning (or error if we promote it to that). Some projects are using that now. We need to get "clean" before we can turn that on more broadly though.
/// <typeparam name="T">The type of the header. | ||
/// The given type must have a static TryParseList method</typeparam> | ||
/// <param name="name">The name of the header to retrieve.</param> | ||
/// <returns>List of values of the header</returns> |
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.
/// <returns>List of values of the header</returns> | |
/// <returns>List of values of the header.</returns> |
/// <summary> | ||
/// Gets the values of header with <paramref name="name"/>. | ||
/// </summary> | ||
/// <remarks><typeparamref name="T"/> must contain a TryParseList method with the signature <code>public static bool TryParseList(IList<string>, out IList<T>)</code></remarks> |
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 used typeparamref
here but not in the Get
method. I'm fine with doing this either way but we should be consistent.
Similarly, you put the full signature in here, but not above.
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.
We should also be consistent between remarks
and typeparam
items. Let's make them similar in format and consistent between both methods.
/// <summary> | ||
/// Gets the values of header with <paramref name="name"/>. | ||
/// </summary> | ||
/// <remarks><typeparamref name="T"/> must contain a TryParseList method with the signature <code>public static bool TryParseList(IList<string>, out IList<T>)</code></remarks> |
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.
Same comments about consistency apply here.
This comment was made automatically. If there is a problem contact [email protected]. I've triaged the above build. I've created/commented on the following issue(s) |
@HaoK Build Tests: Helix x64 still looks too flaky to be required. |
Looks like there might be something going on with redis causing these tests to fail:
|
Thanks |
Summary of the changes (Less than 80 chars)
Addresses #3465