admin/PowerShell-PowerShell
1
0
Fork 0
mirror of https://github.com/PowerShell/PowerShell synced 2026-06-08 12:12:50 +00:00
Code Issues Packages Projects Releases Wiki Activity

Update coding guidelines (#4754)

Browse Source 
* Update coding guidelines to make it more concrete and useful in a review process.

* Add a section about security

* Address comments

* Update .spelling

* Address more comments

* Address comment about the security section

* Fix 'i.e.' and 'e.g.'

* Update .spelling

* One more tweak

* Add motivation for using 'nameof'
This commit is contained in:
Dongbo Wang
2017-09-08 20:24:26 +04:00
committed by Ilya
parent fc9d798b77
commit ca1d2acfba
4 changed files with 200 additions and 74 deletions
Download Patch File Download Diff File Expand all files Collapse all files
.github/CODEOWNERS
+1 -1
View File
@@ -10,7 +10,7 @@
# @BrucePay @JamesWTruher
# Area: Security
# @TravisEz13 @PaulHigin @chunqingchen
# @TravisEz13 @PaulHigin
# Area: Documentation
# @joeyaiello @TravisEz13
.github/CONTRIBUTING.md
+13 -5
View File
@@ -111,15 +111,23 @@ Additional references:
![Github-PR-dev.png](Images/Github-PR-dev.png)
* It's recommended to avoid a PR with too many changes.
A large PR not only stretches the review time, but also makes it much harder to spot issues.
In such case, it's better to split the PR to multiple smaller ones.
For large features, try to approach it in an incremental way, so that each PR won't be too big.
* If you're contributing in a way that changes the user or developer experience, you are expected to document those changes.
See [Contributing to documentation related to PowerShell](#contributing-to-documentation-related-to-powershell).
* Add a meaningful title of the PR describing what change you want to check in.
Don't simply put: "Fixes issue #5".
A better example is: "Add Ensure parameter to New-Item cmdlet", with "Fixes #5" in the PR's body.
Don't simply put: "Fix issue #5".
Also don't directly use the issue title as the PR title.
An issue title is to briefly describe what is wrong, while a PR title is to briefly describe what is changed.
A better example is: "Add Ensure parameter to New-Item cmdlet", with "Fix #5" in the PR's body.
* When you create a pull request,
including a summary of what's included in your changes and
if the changes are related to an existing GitHub issue,
please reference the issue in pull request description (e.g. ```Closes #11```).
including a summary about your changes in the PR description.
The description is used to create change logs,
so try to have the first sentence explain the benefit to end users.
If the changes are related to an existing GitHub issue,
please reference the issue in PR description (e.g. ```Fix #11```).
See [this][closing-via-message] for more details.
* If the change warrants a note in the [changelog](../CHANGELOG.MD)
either update the changelog in your pull request or