jeans/developers.home-assistant
jeans/developers.home-assistant
1
0
Fork 0
mirror of https://github.com/home-assistant/developers.home-assistant.git synced 2025-07-13 20:36:29 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update component code review

Browse Source
This commit is contained in:
andrewsayre 2019-03-26 19:28:27 -05:00
parent 2fcdbf8941
commit 461caf6fd5
1 changed files with 11 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

13
docs/creating_component_code_review.md
View File

@ -11,6 +11,8 @@ A checklist of things to do when you're adding a new component.
1. Follow our [Style guidelines](development_guidelines.md)
2. Use existing constants from [`const.py`](https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/const.py)
* Only add new constants to `const.py` if they are widely used. Otherwise keep them on components level
3. Add yourself to [`CODEOWNERS`](https://github.com/home-assistant/home-assistant/blob/dev/CODEOWNERS) so you [automatically get requested to review](https://help.github.com/en/articles/about-code-owners#codeowners-syntax) the code when it changes in the future
4. Rebase (**do not merge**) to (catch up with latest dev branch)[https://developers.home-assistant.io/docs/en/development_catching_up.html]
### 1. Requirements
@ -47,8 +49,15 @@ bridge = Bridge(...)
status = bridge.status()
```
### 5. Limit platforms included in initial pull request
Large pull requests mean there is a larger chance of finding problems that need to be addressed, and more code that needs to be reviewed between every requested change. If your new component will have multiple platforms, try and limit your initial pull request to a single platform. Once the initial component is merged, you can submit additional PRs for the remaining platforms. This allows reviewers to sign off on smaller chunks of code one at a time, and lets us get your new feature in sooner. Pull requests containing large code dumps will not be a priority for review.
### 5. Limit initial pull request to Minimum Viable Product (MVP)
Large pull requests mean there is a larger chance of finding problems that need to be addressed, and more code that needs to be reviewed between every requested change. Limit the initial pull request to the minimum functionality needed for someone to get value out of the integration. Once the initial pull request is merged, you can submit additional PRs for the remaining features. This allows reviewers to sign off on smaller chunks of code one at a time, and lets us get your new integration/features in sooner. **Pull requests containing large code dumps (> 800 line adds excluding tests) will not be a priority for review and may be closed.** Limit MVPs to the following:
- A single platform
- No custom services
- Loaded via `configuration.yaml` _or_ config flow (if `configuration.yaml` cannot be used)
- No other features outside of supporting the single platform
### 6. Event names
Prefix component event names with the component name itself. For example, use `netatmo_person` instead of `person` for the `netatmo` component.
### 7. Tests
Strongly consider adding tests for your component to ensure it works correctly. Pull Requests with tests are treated with a higher priority than those without.