-
Notifications
You must be signed in to change notification settings - Fork 3.5k
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
[DOCS][COMMUNITY] Improve code review guideline on API designs #2459
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.
minor nits
docs/contribute/code_review.rst
Outdated
Hold the Highest Standard | ||
------------------------- | ||
The first rule for code reviewers is to always keep the highest standard, and do not approve code just to "be friendly". Good, informative critics each other learn and prevents technical debt in early stages. | ||
|
||
Deliberate on API and Data Structures | ||
------------------------------------- | ||
A minimum and stable API is critical to the project’s life. A good API makes a huge difference. Always think very carefully about all the aspects including naming, arguments definitions and behavior. |
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.
nit: argument definitions
docs/contribute/code_review.rst
Outdated
Here are some useful principles for designing APIs: | ||
|
||
- Be consistent with existing well-known package’s APIs if the feature overlap. | ||
For example, tensor operation APIs should always be consistent with the numpy. |
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.
nit: numpy [API]
docs/contribute/code_review.rst
Outdated
- Be consistent with existing APIs in the same project. | ||
For example, we should use the same argument ordering across all the optimization passes, | ||
so there is no "surprise" when using them. | ||
- Think about whether API will change in the future. |
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.
nit: [the] API
docs/contribute/code_review.rst
Outdated
For example, we should use the same argument ordering across all the optimization passes, | ||
so there is no "surprise" when using them. | ||
- Think about whether API will change in the future. | ||
For example, we will have more options like loop_unrolling, device placement policy |
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.
loop unrolling [and] device placement policy
docs/contribute/code_review.rst
Outdated
so there is no "surprise" when using them. | ||
- Think about whether API will change in the future. | ||
For example, we will have more options like loop_unrolling, device placement policy | ||
as we add more optimization in build. We can package optimization knobs into a build |
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.
nit: optimization[s] in build
docs/contribute/code_review.rst
Outdated
For example, we will have more options like loop_unrolling, device placement policy | ||
as we add more optimization in build. We can package optimization knobs into a build | ||
configuration object. So that the build API is stable over time. | ||
- Write down documents. Documents are mandatory for APIs, sometimes writing documents helps |
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.
APIs [and] sometimes
docs/contribute/code_review.rst
Outdated
configuration object. So that the build API is stable over time. | ||
- Write down documents. Documents are mandatory for APIs, sometimes writing documents helps | ||
us to think about whether we need clarification. | ||
- Minimum. Think about how many lines of code a user have to write to use the API. |
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.
a user [has] to write
Thanks to @eqy @ZihengJiang , this is now merged |
Update code review guidelines to emphasize more on API designs. API design is what we sometimes overlooked, and we should learn from projects like numpy, pytorch and keras.
cc @dmlc/tvm-comitter