harmony 鸿蒙Review Application for the API in the OpenHarmony Subsystem
Review Application for the API in the OpenHarmony Subsystem
Background
- API type: [Public API|System API|Test API|HDI]
- API requirement source:
- API usage scenario:
- Belonging subsystem:
- Expected API release version:
- Contributor:
- Number of APIs involved in this review:
| Change Type | Quantity | Programming Language |
|---|---|---|
| Added | ||
| Behavior changed | ||
| Deprecated | ||
| Deleted |
API Description
Necessity of the Changes
Based on the as-is and gap analysis, describe what the application scenarios and benefits of the APIs are.
Feature Overview
Describe features implemented by the APIs.
Review Conclusion
Review Conclusion from Committers
Review Conclusion from Domain SIGs
Self-Check Table
| Self-Check Item | Self-Check Result |
|---|---|
| Is the spelling check completed? | |
| Are coding specifications complied with? | |
| Are parts of speech (noun, adjective, adverb) used correctly? | |
| Does the API name fully describe the API logic? | |
| Is the number of API parameters appropriate? (Generally, there should be fewer than 7 parameters.) | |
| Are abbreviations properly used? (Abbreviations used should be well known.) | |
| Is it really that the caller of a void API does not need a return value? | |
| Is the inheritance system appropriate? Does every method of a parent class apply to its child classes? | |
| Are all possible error states included and defined? | |
| Is the group of antonyms used correctly, for example: add/remove, create/destroy, insert/delete, start/stop, begin/end, send/receive, up/down, show/hide, open/close, source/target, source/destination, increase/decrease, first/last, next/previous |
|
| Are the description and semantic hierarchy of new APIs consistent with those of existing APIs in the same module? | |
| Are asynchronous counterparts needed for synchronous APIs? | |
| Are all the public APIs truly required by developers? |
API Description
Enter the code commit address.
- Code address:
API Permission Design
Specify whether developers need to apply for certain permissions to use the APIs.
API Privacy Protection Design
If user privacy data is involved, privacy protection must be considered.
Developer Guide
Optional.
API Code Example
Select either of the following:
- Code address:
- Code snippet:
API Updates
Only required for existing APIs.
Behavior Change
The API behavior change indicates that the API only has its behavior changed. The new API behavior must be released in a new version. You should not change the API behavior without releasing a new version (except for defect rectification).
Related APIs
Reason for the Change
Deprecated APIs
Add the
@deprecatedannotation to the description of deprecated APIs (including JS, TS, C, and C++ APIs).
Related APIs
State the version from which the API is annotated by
@deprecated.
Reason for Deprecation
Substitute APIs
List the APIs provided to substitute the deprecated ones. If there are no substitute APIs provided, describe the reason.
Deleted APIs
An API can be deleted only after five API versions have been released since it is marked as deprecated.
Related APIs
Reason for Deletion
Substitute APIs
List the APIs provided to substitute the deleted ones. If there are no substitute APIs provided, describe the reason.
DFX
Compatibility
Performance
Power Consumption
Reliability
Testability
Automatic API test cases must be delivered for all APIs.
Review Conclusion
- Reviewed on:
- Reviewers:
- Review conclusion: [Pass|Fail]
- Review meeting minutes:
你可能感兴趣的鸿蒙文章
harmony 鸿蒙OpenHarmony API Governance Charter
harmony 鸿蒙OpenHarmony API Design Specifications
- 所属分类： 后端技术
- 本文标签：
热门推荐
-
2、 - 优质文章
-
3、 gate.io
-
6、 golang
-
7、 openharmony