-
Notifications
You must be signed in to change notification settings - Fork 3.8k
[DOCS][COMMUNITY] Improve code review guideline on API designs #2459
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
Conversation
eqy
left a comment
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
|
|
||
| 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