Skip to content

Commit

Permalink
Add seeds for docfx
Browse files Browse the repository at this point in the history
  • Loading branch information
vicancy committed Nov 26, 2015
1 parent cc9cf84 commit 21683f3
Show file tree
Hide file tree
Showing 27 changed files with 1,780 additions and 1 deletion.
42 changes: 42 additions & 0 deletions .gitignore
Original file line number Diff line number Diff line change
@@ -0,0 +1,42 @@
###############
# folder #
###############
/**/DROP/
/**/TEMP/
/**/packages/
/**/bin/
/**/csx/
/**/obj/
/**/xdocoutput/
/**/node_modules/
/**/*.sln.ide/
/TestResults/
/.vs/
.NuGet/
artifacts/
target/
/**/_site/
.vscode/
.vs/

###############
# temp file #
###############
*.nupkg
*.log
*.tmp
*.vsprops
*.suo
*.user
*.userprefs
*.sdf
*.sln.ide
*.cache
*.sln.metaproj
.gitattributes
.settings
log.txt
debugSettings.json
launchSettings.json
project.lock.json
*.sublime-workspace
27 changes: 26 additions & 1 deletion README.md
Original file line number Diff line number Diff line change
@@ -1,2 +1,27 @@
# docfx-seed
A sample documentation project, containing .NET source code and markdown files, can generate a static website after running docfx
## Description
This is a sample docfx documentation project. It contains .NET source code and markdown files.
`docfx.json` is the configuration file for running `docfx`.
`docfx` will generate a static website as similar to .

## How to run
### Under Windows
* Download and unzip [docfx.zip](http://aspnet.github.io/docfx/tutorial/artifacts/docfx.zip) to run `docfx.exe` directly!
* Run `docfx` under current repo! Website will be generated under `_site` folder.
* Run any web hosting tool to host `_site` folder, e.g. `docfx serve _site`.

### Cross platform and use `dnx`
As a prerequisite, you will need to install [DNVM](http://docs.asp.net/en/latest/getting-started/installing-on-windows.html#install-the-net-version-manager-dnvm) and [DNX](http://docs.asp.net/en/latest/getting-started/installing-on-windows.html#install-the-net-execution-environment-dnx).
###Quick Start
* `dnvm upgrade` to get the latest dnvm.
* Add feed https://www.myget.org/F/aspnetrelease/api/v2/ to Nuget.config
> For Windows, the nuget config file is **%AppData%\NuGet\NuGet.config**.
> For Linux/OSX, the nuget config file is **~/.config/NuGet/NuGet.config**.
```
* `dnu commands install docfx` to install `docfx` as a command
* Run `docfx` under current repo! Website will be generated under `_site` folder.
* Run any web hosting tool to host `_site` folder, e.g. `docfx serve _site`.
## Further information about `docfx`
`docfx` is a tool to generate documentation towards .NET source code and markdown files. Please refer to [docfx](http://aspnet.github.io/docfx/tutorial/docfx_getting_started.html) to get start. The `docfx` website itself is generated by `docfx`!
219 changes: 219 additions & 0 deletions articles/csharp_coding_standards.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,219 @@
C# Coding Standards
====================

Introduction
----------------
The coding standard will be used in conjunction with customized version of *StyleCop* and *FxCop* [**TODO**] during both development and build process. This will help ensure that the standard is followed by all developers on the team in a consistent manner.

>"Any fool can write code that a computer can understand. Good programmers write code that humans understand".
>
> Martin Fowler. *Refactoring: Improving the design of existing code.*
### Purpose

The aim of this section is to define a set of C# coding standards to be used by CAPS build team to guarantee maximum legibility, reliability, re-usability and homogeneity of our code. Each section is marked *Mandatory* or *Recommended*. *Mandatory* sections, will be enforced during code reviews as well as tools like *StyleCop* and *FxCop*, and code will not be considered complete until it is compliant.

### Scope

This section contains general C# coding standards which can be applied to any type of application developed in C#, based on *[Framework Design Guidelines](http://msdn.microsoft.com/en-us/library/ms229042.aspx)*.

It does not pretend to be a tutorial on C#. It only includes a set of limitations and recommendations focused on clarifying the development.

Tools
----------------

* [Resharper](http://www.jetbrains.com/resharper/) is a great 3rd party code cleanup and style tool.
* [StyleCop](http://stylecop.codeplex.com/) analyzes C# srouce code to enforce a set of style and consistency rules and has been integrated into many 3rd party development tools such as Resharper.
* [FxCop](http://codebox/SDLFxCop) is an application that analyzes managed code assemblies (code that targets the .NET Framework common language runtime) and reports information about the assemblies, such as possible design, localization, performance, and security improvements.
* [C# Stylizer](http://toolbox/22561) does many of the style rules automatically

Highlights of Coding Standards
------------------------------

This section is not intended to give a summary of all the coding standards that enabled by our customized StyleCop, but to give a highlight of some rules one will possibly meet in daily coding life. It also provides some recommended however not mandatory(which means not enabled in StyleCop) coding standards.

### File Layout (Recommended)
Only one public class is allowed per file.

The file name is derived from the class name.

Class : Observer
Filename: Observer.cs

### Class Definition Order (Mandatory)

The class definition contains class members in the following order, from *less* restricted scope (public) to *more* restrictive (private):

* Nested types, e.g. classes, enum, struct, etc.
* Field members, e.g. member variables, const, etc.
* Member functions
* Constructors
* Finalizer (Do not use unless absolutely necessary)
* Methods (Properties, Events, Operations, Overridables, Static)
* Private nested types

### Naming (Mandatory)
* **DO** use PascalCasing for all public member, type, and namespace names consisting of multiple words.

PropertyDescriptor
HtmlTag
IOStream
**NOTE**: A special case is made for two-letter acronyms in which both letters are capitalized, e.g. *IOStream*
* **DO** use camelCasing for parameter names.

propertyDescriptor
htmlTag
ioStream

* **DO** start with underscore for private fields

private readonly Guid _userId = Guid.NewGuid();

* **DO** start static readonly fields, constants with capitalized case

private static readonly IEntityAccessor EntityAccessor = null;
private const string MetadataName = "MetadataName";

* **DO NOT** capitalize each word in so-called [closed-form compound words](http://msdn.microsoft.com/en-us/library/ms229043.aspx).

* **DO** have **"Async"** explicitly in the Async method name to notice people how to use it properly

### Formatting (Mandatory)
* **DO** use spaces over tabs, and always show all spaces/tabs in IDE

> **Tips**
>
> Visual Studio > TOOLS > Options > Text Editor > C# > Tabs > Insert spaces (Tab size: 4)
>
> Visual Studio > Edit > Advanced > View White Space
* **DO** add *using* inside *namespace* declaration

namespace Microsoft.Content.Build.BuildWorker.UnitTest
{
using System;
}

* **DO** add a space when:
1. `for (var i = 0; i < 1; i++)`
2. `if (a == b)`

### Cross-platform coding
Our code should supports multiple operating systems. Don't assume we only run (and develop) on Windows. Code should be sensitvie to the differences between OS's. Here are some specifics to consider.

* **DO** use `Enviroment.NewLine` instead of hard-coding the line break instead of `\r\n`, as Windows uses `\r\n` and OSX/Linux uses `\n`.

> **Note**
>
> Be aware that thes line-endings may cause problems in code when using `@""` text blocks with line breaks.
* **DO** Use `Path.Combine()` or `Path.DirectorySeparatorChar` to separate directories. If this is not possible (such as in scripting), use a forward slash `/`. Windows is more forgiving than Linux in this regard.

### Unit tests and functional tests
#### Assembly naming
The unit tests for the `Microsoft.Foo` assembly live in the `Microsoft.Foo.Tests` assembly.

The functional tests for the `Microsoft.Foo` assmebly live in the `Microsoft.Foo.FunctionalTests` assmebly.

In general there should be exactly one unit test assebmly for each product runtime assembly. In general there should be one functional test assembly per repo. Exceptions can be made for both.

#### Unit test class naming
Test class names end with `Test` and live in the same namespace as the class being tested. For example, the unit tests for the `Microsoft.Foo.Boo` class would be in a `Microsoft.Foo.Boo` class in the test assembly.

#### Unit test method naming
Unit test method names must be descriptive about *what is being tested, under what conditions, and what the expectations are*. Pascal casing and underscores can be used to improve readability. The following test names are correct:

```cs
PublicApiArgumentsShouldHaveNotNullAnnotation
Public_api_arguments_should_have_not_null_annotation
```

The following test names are incorrect:

```cs
Test1
Constructor
FormatString
GetData
```

#### Unit test structure
The contents of every unit test should be split into three distinct stages, optionally separated by these comments:

```cs
// Arrange
// Act
// Assert
```

The crucial thing here is the `Act` stage is exactly one statement. That one statement is nothing more than a call to the one method that you are trying to test. keeping that one statement as simple as possible is also very important. For example, this is not ideal:

```cs
int result = myObj.CallSomeMethod(GetComplexParam1(), GetComplexParam2(), GetComplexParam3());
```

This style is not recomended because way too many things can go wrong in this one statement. All the `GetComplexParamN()` calls can throw for a variety of reasons unrelated to the test itself. It is thus unclear to someone running into a problem why the failure occured.

The ideal pattern is to move the complex parameter building into the `Arrange section:

```cs
// Arrange
P1 p1 = GetComplexParam1();
P2 p2 = GetComplexParam2();
P3 p3 = GetComplexParam3();

// Act
int result = myObj.CallSomeMethod(p1, p2, p3);

// Assert
Assert.AreEqual(1234, result);
```

Now the only reason the line with `CallSomeMethod()` can fail is if the method itself blew up.

#### Testing exception messages

In general testing the specific exception message in a unit test is important. This ensures that the exact desired exception is what is being tested rather than a different exception of the same type. In order to verify the exact exception it is important to verify the message.

```cs
var ex = Assert.Throws<InvalidOperationException>(
() => fruitBasket.GetBananaById(1234));
Assert.Equal(
"1234",
ex.Message);
```

#### Use xUnit.net's plethora of built-in assertions
xUnit.net includes many kinds of assertions – please use the most appropriate one for your test. This will make the tests a lot more readable and also allow the test runner report the best possible errors (whether it's local or the CI machine). For example, these are bad:

```cs
Assert.Equal(true, someBool);

Assert.True("abc123" == someString);

Assert.True(list1.Length == list2.Length);

for (int i = 0; i < list1.Length; i++) {
Assert.True(
String.Equals
list1[i],
list2[i],
StringComparison.OrdinalIgnoreCase));
}
```

These are good:

```cs
Assert.True(someBool);

Assert.Equal("abc123", someString);

// built-in collection assertions!
Assert.Equal(list1, list2, StringComparer.OrdinalIgnoreCase);
```

#### Parallel tests
By default all unit test assemblies should run in parallel mode, which is the default. Unit tests shouldn't depend on any shared state, and so should generally be runnable in parallel. If the tests fail in parallel, the first thing to do is to figure out why; do not just disable parallel tests!

For functional tests it is reasonable to disable parallel tests.
Loading

0 comments on commit 21683f3

Please sign in to comment.