Skip to content
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

A few small nits #1

Open
3 of 8 tasks
dgryski opened this issue Feb 9, 2018 · 1 comment
Open
3 of 8 tasks

A few small nits #1

dgryski opened this issue Feb 9, 2018 · 1 comment

Comments

@dgryski
Copy link

dgryski commented Feb 9, 2018

I've only quickly glanced over the code but I've noticed a few things:

  • there are a few places you call log.Printf and then os.Exit. You can just call log.Fatalf instead, which does the same thing.
  • instead of calling r.ReadString('\n'), use a bufio.Scanner: https://golang.org/pkg/bufio/#Scanner , it's a nicer API.
  • remember that a reader can return io.EOF and data that was partially read. In the case of ReadString, you're assured that err != nil iff the data doesn't end in the delimiter, which in your case means likely an incomplete line was read, but it's still good to document that you're discarding a potentially incomplete line.
  • your case in parseEvent returns an empty string for the error when the broadcast packet doesn't have two fields
  • the cases for 'F', 'U', and 'P' can be combined: case "F", "U", "P": ...
  • you're calling recover() directly. In order to catch a panic, recover() needs to be in a defer and you need to check the return value from recover to see if you're actually panicking or not.
  • you're trying to trap os.Kill, which is SIGKILL, which you can't catch. You probably meant SIGTERM (but there's no constant for that in the os package, just pull syscall.SIGTERM directly.
  • I'm not sure of the performance requirements here, but there's a lot of copying []byte -> string -> []byte. It's probably worth profiling to see if you can do away with the extra string conversion which will involve both a memory allocation and a data copy.
@sahildua2305
Copy link
Owner

sahildua2305 commented Feb 9, 2018

Thanks a lot for reviewing and listing improvements @dgryski ❤️

I'll get to fixing/improving the things you mentioned one at a time soon.

EDIT: I took the liberty to modify the issue description into a checklist so that I can easily keep track of things to fix.

sahildua2305 added a commit that referenced this issue Feb 14, 2018
Because well, as per Go docs here(https://golang.org/pkg/log/#Fatalln):
"Fatalln is equivalent to Println() followed by a call to os.Exit(1)."

Also, thanks to @dgryski for pointing it out in:
#1
sahildua2305 added a commit that referenced this issue Feb 14, 2018
This was most probably just a missed error message while refactoring the
code around parseEvent.

Reported in #1.
sahildua2305 added a commit that referenced this issue Feb 18, 2018
Cases for "F", "U" and "P" in parseEvent method were identical and hence
can be combined to avoid code duplication.

Reported in #1.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants