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

[DOCS][COMMUNITY] Improve code review guideline on API designs #2459

Merged
merged 2 commits into from
Jan 18, 2019

Conversation

tqchen
Copy link
Member

@tqchen tqchen commented Jan 18, 2019

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

Copy link
Contributor

@eqy eqy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

minor nits

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: argument definitions

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: numpy [API]

- 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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: [the] API

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
Copy link
Contributor

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

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
Copy link
Contributor

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

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
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

APIs [and] sometimes

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.
Copy link
Contributor

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

@tqchen tqchen merged commit f7d0883 into apache:master Jan 18, 2019
@tqchen
Copy link
Member Author

tqchen commented Jan 18, 2019

Thanks to @eqy @ZihengJiang , this is now merged

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

Successfully merging this pull request may close these issues.

3 participants