Move Documentation/File guidance into Coding Style and Convention page

This commit is contained in:
michael-hawker 2020-10-28 17:32:00 -07:00
Родитель b20cf6ec88
Коммит 28a161c9a8
3 изменённых файлов: 14 добавлений и 14 удалений

Просмотреть файл

@ -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