-
Notifications
You must be signed in to change notification settings - Fork 114
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
documentation: add further clarification to comments and documentation #12
documentation: add further clarification to comments and documentation #12
Conversation
I'm personally a fan of imperative commit titles, and the commits we have pushed so far follow this style, so I would recommend "add further clarification" instead of "added further clarification". |
@trevorstarick Thank you for updating the PR title. When you have a moment can you please amend your commit with @acln0's suggested change as well? |
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 looks great, thank you for the contribution! There are a few minor tweaks I think we should look at making to be more clear, or precise, in certain areas.
Let me know what you think about the suggestions.
codec.go
Outdated
// FromBytesOrNil returns UUID converted from raw byte slice input. | ||
// Same behavior as FromBytes, but returns a Nil UUID on error. | ||
// FromBytesOrNil returns a UUID generated from the raw byte slice input. | ||
// Same behavior as FromBytes(), but returns a Nil UUID instead of an error. |
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 reads a bit strange to me. How about something like:
This has the same behavior as FromBytes(), but returns a nil UUID instead of an error.
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.
Should I call it a nil UUID
even though it's referring to the special UUID type, Nil
codec.go
Outdated
// FromStringOrNil returns UUID parsed from string input. | ||
// Same behavior as FromString, but returns a Nil UUID on error. | ||
// FromStringOrNil returns a UUID parsed from the input string. | ||
// Same behavior as FromString(), but returns a Nil UUID instead of an error. |
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.
Similar as my other comment:
This has the same behavior as..
Also would you be able to lowercase "Nil"?
codec.go
Outdated
@@ -108,7 +108,7 @@ func (u *UUID) UnmarshalText(text []byte) (err error) { | |||
} | |||
} | |||
|
|||
// decodeCanonical decodes UUID string in format | |||
// decodeCanonical decodes UUID strings that are formatted like the following format: |
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.
To point people to the origin of the format, would you be opposed to citing the RFC and section?
strings that are formatted as defined in RFC-4122 (section 3):
codec.go
Outdated
@@ -133,8 +133,8 @@ func (u *UUID) decodeCanonical(t []byte) (err error) { | |||
return | |||
} | |||
|
|||
// decodeHashLike decodes UUID string in format | |||
// "6ba7b8109dad11d180b400c04fd430c8". | |||
// decodeHashLike decodes UUID strings that are formatted like the following format: |
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.
strings that are using the following format:
codec.go
Outdated
// decodeBraced decodes UUID string in format | ||
// "{6ba7b810-9dad-11d1-80b4-00c04fd430c8}" or in format | ||
// "{6ba7b8109dad11d180b400c04fd430c8}". | ||
// decodeBraced decodes UUID strings that are formatted like the following formats: |
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.
How do you feel about something like this for this ones, and the rest in the file?
strings that are using the following formats:
uuid.go
Outdated
// | ||
// RFC 4122 (https://tools.ietf.org/html/rfc4122) provides the specification for versions 1, 3, 4, and 5. | ||
// | ||
// DCE 1.1 (http://pubs.opengroup.org/onlinepubs/9696989899/chap5.htm#tagcjh_08_02_01_01) provides the specification for version 2. |
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.
Would you be willing to wrap the lines in this section to look more natural in relation to the license above?
// Package uuid provides implementations of the Universally Unique Identifier
// (UUID), as specified in RFC 4122 and DCE 1.1.
//
// RFC 4122 (https://tools.ietf.org/html/rfc4122) provides the specification for
// versions 1, 3, 4, and 5.
//
// DCE 1.1[1] provides the specification for version 2.
//
// [1] http://pubs.opengroup.org/onlinepubs/9696989899/chap5.htm#tagcjh_08_02_01_01
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.
@trevorstarick actually, how do you feel about adding references to both?
// Package uuid provides implementations of the Universally Unique Identifier
// (UUID), as specified in RFC-4122[1] and DCE 1.1[2].
//
// RFC 4122 (https://tools.ietf.org/html/rfc4122) provides the specification for
// versions 1, 3, 4, and 5.
//
// DCE 1.1 provides the specification for version 2.
//
// [1] https://tools.ietf.org/html/rfc4122
// [2] http://pubs.opengroup.org/onlinepubs/9696989899/chap5.htm#tagcjh_08_02_01_01
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 originally did this, but found it weird to look at. Now that I've added more content I think it should look better.
uuid.go
Outdated
@@ -67,8 +68,7 @@ var ( | |||
byteGroups = []int{8, 4, 4, 4, 12} | |||
) | |||
|
|||
// Nil is special form of UUID that is specified to have all | |||
// 128 bits set to zero. | |||
// Nil is special form of UUID that is specified to have all 128 bits set to zero. |
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 refer back to the name used in the RFC:
Nil is a nil UUID, as specified in RFC-4122, that has all 128 bits set to zero.
uuid.go
Outdated
func (u UUID) Bytes() []byte { | ||
return u[:] | ||
} | ||
|
||
// Returns canonical string representation of UUID: | ||
// String returns a canonical string representation of the UUID: |
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'd add RFC-4122
after the word canonical to make it more precise.
@@ -152,7 +152,7 @@ func (u *UUID) SetVariant(v byte) { | |||
// Must is a helper that wraps a call to a function returning (UUID, error) | |||
// and panics if the error is non-nil. It is intended for use in variable | |||
// initializations such as | |||
// var packageUUID = uuid.Must(uuid.FromString("123e4567-e89b-12d3-a456-426655440000")); |
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.
;
Hahahaha! Nice find! 😂
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.
When you have a moment can you please squash all these commits down to one?
If you aren't familiar with that hit me up on Slack.
@trevorstarick As a heads-up, this branch still has two commits in it. My preferred preference is to do things as one atomic commit, when making changes like this. Here are the two commits I see:
It's not a huge deal, so to avoid a continued back-and forth on this PR I'll merge this branch as-is. |
…umentation Merge branch 'trevorstarick-trevorstarick-improving-documentation' Signed-off-by: Tim Heckman <t@heckman.io>
No description provided.