Move Documentation/File guidance into Coding Style and Convention page
This commit is contained in:
Родитель
b20cf6ec88
Коммит
28a161c9a8
|
@ -2,7 +2,7 @@ In general, the project follows the [C# Coding Convention](https://docs.microsof
|
||||||
|
|
||||||
* DO NOT require that users perform any extensive initialization before they can start programming basic scenarios.
|
* DO NOT require that users perform any extensive initialization before they can start programming basic scenarios.
|
||||||
* DO provide good defaults for all values associated with parameters, options, etc.
|
* DO provide good defaults for all values associated with parameters, options, etc.
|
||||||
* DO ensure that APIs are intuitive and can be successfully used in basic scenarios without referring to the reference documentation.
|
* DO ensure that APIs are intuitive and can be successfully used in basic scenarios without referring to the reference documentation (though see below).
|
||||||
* DO communicate incorrect usage of APIs as soon as possible.
|
* DO communicate incorrect usage of APIs as soon as possible.
|
||||||
* DO design an API by writing code samples for the main scenarios. Only then, you define the object model that supports those code samples.
|
* DO design an API by writing code samples for the main scenarios. Only then, you define the object model that supports those code samples.
|
||||||
* DO NOT use regions. DO use partial classes instead.
|
* DO NOT use regions. DO use partial classes instead.
|
||||||
|
@ -13,4 +13,17 @@ In general, the project follows the [C# Coding Convention](https://docs.microsof
|
||||||
* DO use verbs like GET.
|
* DO use verbs like GET.
|
||||||
* DO NOT use verbs that are not already used like fetch.
|
* DO NOT use verbs that are not already used like fetch.
|
||||||
|
|
||||||
|
### Documentation
|
||||||
|
|
||||||
|
* DO NOT expect that your API is so well designed that it needs no documentation. No API is that intuitive.
|
||||||
|
* DO provide great documentation with all APIs.
|
||||||
|
* DO use readable and self-documenting identifier names.
|
||||||
|
* DO use consistent naming and terminology.
|
||||||
|
* DO provide strongly typed APIs.
|
||||||
|
* DO use verbose identifier names.
|
||||||
|
|
||||||
|
### Files and Folders
|
||||||
|
|
||||||
|
* DO NOT create a new namespace for every folder.
|
||||||
|
* DO associate no more than one class per file.
|
||||||
|
* DO use folders to group classes based on features.
|
||||||
|
|
|
@ -1,12 +0,0 @@
|
||||||
* DO NOT expect that your API is so well designed that it needs no documentation. No API is that intuitive.
|
|
||||||
* DO provide great documentation with all APIs.
|
|
||||||
* DO use readable and self-documenting identifier names.
|
|
||||||
* DO use consistent naming and terminology.
|
|
||||||
* DO provide strongly typed APIs.
|
|
||||||
* DO use verbose identifier names.
|
|
||||||
|
|
||||||
### Files and Folders
|
|
||||||
|
|
||||||
* DO associate no more than one class per file.
|
|
||||||
* DO use folders to group classes based on features.
|
|
||||||
|
|
|
@ -35,7 +35,6 @@
|
||||||
* [[Coding Style and Conventions]] ⚖
|
* [[Coding Style and Conventions]] ⚖
|
||||||
* [[Accessibility Guideline]] ♿
|
* [[Accessibility Guideline]] ♿
|
||||||
* [[Avoid Roadblocks]] 🚧
|
* [[Avoid Roadblocks]] 🚧
|
||||||
* [[Documentation]] 📃
|
|
||||||
|
|
||||||
### Development/Testing
|
### Development/Testing
|
||||||
|
|
||||||
|
|
Загрузка…
Ссылка в новой задаче