-
Notifications
You must be signed in to change notification settings - Fork 88
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
Idiomatic Go Style notes #18
Comments
BTW in: b[3] = byte(pts >> 7 & 0xff) // PTS[14..8] The 14..8 and 7..0 should be 14..7 and 6..0. The &0xff is also redundant. |
Thank you! Your comments are certainly helpful. I didn't realize that there was already a conversation about |
A lot of these recommendations are pretty trivial, and I think useful to make the code more idiomatic and helpful for new users. If nobody else is working on cleanup, I'd be happy to help if it wouldn't be duplicating effort. |
Go for it. The only things we changed so far were the build issues. I just put the CLA in the repo too. (https://github.com/Comcast/gots/blob/master/CLA.pdf) |
My 5¢: Enum-like types like I'd suggest changing pmtstreamtype.go to the following: type PmtStreamType uint8
const (
PmtStreamTypeMpeg2VideoH262 PmtStreamType = 2 // H262
PmtStreamTypeMpeg4Video = 27 // H264
...
PmtStreamTypeIpmp = 25
...
)
func (t PmtStreamType) String() string {
switch t {
case PmtStreamTypeMpeg2VideoH262:
return "ITU-T Rec. H.262 | ISO/IEC 13818-2 Video"
case PmtStreamTypeMpeg4Video:
return "AVC video stream as defined in ITU-T Rec. H.264 | ISO/IEC 14496-10 Video"
...
}
// optional
if t >= 196 && t <= 233 {
return "TSC User Private Program Elements"
}
return fmt.Sprintf("0x%02x", int(t))
}
type PmtStreamType interface {
StreamType() PmtStreamType
} This will make it much more comfortable to use. And I'd do the same for |
I just stumbled across this repo, linked to from golang/go#16353, which proposes to add packages under golang.org/x. A necessary but not sufficient condition for golang.org/x is that that code be in idiomatic Go style. Here are some miscellaneous notes on that topic, in no particular order:
First up, it doesn't build. AFAICT, the canonical github URL https://github.com/Comcast/gots has a capital C in Comcast. The import paths in the code are something like "github.com/comcast/gots" with a lower case C. I'm guessing that you're developing on Windows.
The example code in Readme.md doesn't look like it would build. The structure is:
and you're missing an }.
Also, we usually check err != nil (and return early) instead of err == nil.
Also, the ".Error()" in
is redundant. Grep https://golang.org/pkg/fmt/ for "Error" for more details.
The loop:
is incorrect. As per https://golang.org/pkg/io/#Reader, the Read method is allowed to read fewer bytes than the buffer length. You may want https://golang.org/pkg/io/#ReadFull. You might also want a bufio.Reader to avoid lots of small reads.
In package packet:
can be just
can be just
Similarly with func IsPat:
can be just:
The uint8 in
is redundant, as per https://blog.golang.org/constants
Similarly, the int in
is redundant.
Similarly for the uint8 in
The parens in
are unnecessary, and once you remove them, gofmt will emphasize the operator precedence:
can probably be just
as we are already in "package packet", so users of this constant would refer to it as "packet.Size". In the standard library's net/http package, the type is called Server, which users refer to as "http.Server". It's not "type HTTPServer" and "http.HTTPServer". Similarly for many other names in this repo.
Pid should probably be PID, as per https://github.com/golang/go/wiki/CodeReviewComments#initialisms, and similarly it'd be MPEG, AAC, CRC, etc.
"var emptyByteArray []byte" is unnecessary. Instead of:
write:
and similarly, drop the "var emptyByteSlice []byte".
The "Array" in "emptyByteArray" is also incorrect: it's a slice, not an array. In Go, an array has fixed length.
In the _test.go files, the usual Go naming is "want", not "expected".
The outer parens in
are unnecessary.
The byte in
is unnecessary.
The "== false" in:
is usually written:
The "e" variable name in
should be "err".
The blank line in
means that godoc does not associate that first line comment line with the function. Instead, that blank line should be a blank comment line:
The asterisks in
are unnecessary. Packet is already a slice type, which contains an implicit pointer. There's no need for another indirection.
The second "size" in:
is redundant.
The double-parens in:
is unnecessary.
There is a typo with the "creatio" in "This is a convenience function for often used packet creatio options functions".
In func Create:
can be
Doc comments should also be complete sentences, and therefore end with a full stop. https://github.com/golang/go/wiki/CodeReviewComments#comment-sentences
That link also says that "Comments should begin with the name of the thing being described and end in a period", so that the "Parses" in
should instead be
and similarly for various other doc comments in the repo.
I think that
can instead be:
if you are assuming that len(pkg) == PacketSize.
In general, it seems like functions like ContainsPayload, SetPayload and Equal could be methods instead of functions.
The make call in
is probably redundant. A nil slice is a valid (empty) slice. It has length zero, you can range over it (zero times), and you can append to it.
This:
can probably just be
The var b line in
is redundant, and the second can be just:
In package pmtdescriptor:
The receiver name, "descriptor" in
is unusually long. See https://github.com/golang/go/wiki/CodeReviewComments#receiver-names
The constructor function:
could use a struct literal instead:
Go variable names lookLikeThis with camel case, not like representation_id_flag or num_partitions. https://golang.org/doc/effective_go.html#mixed-caps
indx is also an unusual variable name. Just use i.
The atscPmtStreamType type could be an anonymous struct. This:
could instead be
The i++ in
looks like a bug.
Also,
can instead be
The "descriptorsBuf" variable name is also unusually long, for such a short function (pmtElementaryStream.String).
This:
can be:
or if you made Payload a method:
but in the larger loop:
the bytes.Buffer is overkill. If you're just mushing byte slices together, have a "var buffer []byte" at the top and use the append function with dot-dot-dot.
The capital-B in
means that that constant is exported, but I doubt that users of that package would ever refer to psi.BitsPerByte. If that constant is only meant for internal use, the general rule is that we don't export names unless we have to. Similarly, it's not clear to me whether the psi.PointerField function needs to be exported or if it's only meant to be used by other functions inside that package.
There were more directories of code, but I didn't look at them. This note is already long enough.
I also only looked at code style in this note. I did not assess whether the API design style was idiomatic, which is again a necessary but not sufficient condition for moving under golang.org/x.
I hope that this has been helpful. Please let me know if it comes across as overly aggressive.
The text was updated successfully, but these errors were encountered: