-
Notifications
You must be signed in to change notification settings - Fork 31
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
refactor+fix(gossip): update naming in active set and fix table trim condition #184
Conversation
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 thing - otherwise lgtm
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.
few small things - then should be good
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.
lgtm - awesome first pr 🚀
2ec3953
to
2253d2a
Compare
just responding to your comment - then should be good for merge |
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.
lgtm - great first pr 🔥
Overview
Import Style Guide (Draft)
Declare imports in the following groups, separated by a newline.
If it improves clarity, split group's into Sig and External imports / aliases.
Namespaces and Aliases
In my mind, it would be useful to establish some sort of convention for how we alias namespaces, structs, methods etc. For example in service.zig we access structs and methods from src/gossip/data.zig using a mix of approaches. Whilst this is not a big issue, in my opinion it does impact readability so is something to think about.
One approach could be to aim to import structs, methods, constants, etc into the local namespace, and only use namespace aliases when there is a conflict or it improves readability by providing context. For example, importing ContactInfo into the local namespace should never be a problem, but perhaps when using Counter from prometheus in a seperate module prometheus.Counter may be more informative.
Anyway these are just some thoughts which popped up while updating the imports!