GH-78 & GH-77 Completely reorganize and update repo! Added StyleCop (#82)

* Completely reorganize and update repo!

* Add Style Cop and fix all formatting

* Additional Cleanup for rename and organization

* Update readme

* small tweaks :)

Author: jamesmontemagno

Diff for: .editorconfig

@@ -1,11 +1,105 @@
-; This file is for unifying the coding style for different editors and IDEs.
-; More information at http://editorconfig.org
-
+# Suppress: EC112
+# top-most EditorConfig file
 root = true
 
+# Don't use tabs for indentation.
 [*]
-end_of_line = CRLF
-
-[*.cs]
 indent_style = space
+# (Please don't specify an indent_size here; that has too many unintended consequences.)
+
+# Code files
+[*.{cs,csx,vb,vbx}]
+indent_size = 4
+
+# Code files
+[*.sln]
 indent_size = 4
+
+# Xml project files
+[*.{csproj,vbproj,vcxproj,vcxproj.filters,proj,projitems,shproj}]
+indent_size = 2
+
+# Xml config files
+[*.{props,targets,ruleset,config,nuspec,resx,vsixmanifest,vsct}]
+indent_size = 2
+
+# JSON files
+[*.json]
+indent_size = 2
+
+# XML files
+[*.xml]
+indent_size = 2
+
+# Dotnet code style settings:
+[*.{cs,vb}]
+# Sort using and Import directives with System.* appearing first
+dotnet_sort_system_directives_first = true
+# Avoid "this." and "Me." if not necessary
+dotnet_style_qualification_for_field = false:suggestion
+dotnet_style_qualification_for_property = false:suggestion
+dotnet_style_qualification_for_method = false:suggestion
+dotnet_style_qualification_for_event = false:suggestion
+
+# Use language keywords instead of framework type names for type references
+dotnet_style_predefined_type_for_locals_parameters_members = true:suggestion
+dotnet_style_predefined_type_for_member_access = true:suggestion
+
+# Suggest more modern language features when available
+dotnet_style_object_initializer = true:suggestion
+dotnet_style_collection_initializer = true:suggestion
+dotnet_style_coalesce_expression = true:suggestion
+dotnet_style_null_propagation = true:suggestion
+dotnet_style_explicit_tuple_names = true:suggestion
+
+# Naming Conventions:
+# Pascal Casing
+dotnet_naming_symbols.method_and_property_symbols.applicable_kinds= method,property,enum
+dotnet_naming_symbols.method_and_property_symbols.applicable_accessibilities = *
+dotnet_naming_style.pascal_case_style.capitalization = pascal_case
+
+dotnet_naming_rule.methods_and_properties_must_be_pascal_case.severity = warning
+dotnet_naming_rule.methods_and_properties_must_be_pascal_case.symbols = method_and_property_symbols
+dotnet_naming_rule.methods_and_properties_must_be_pascal_case.style = pascal_case_style
+
+# Non-public members must be lower-case
+dotnet_naming_symbols.non_public_symbols.applicable_kinds = field
+dotnet_naming_symbols.non_public_symbols.applicable_accessibilities = private
+dotnet_naming_style.all_lower_case_style.capitalization = camel_case
+
+dotnet_naming_rule.non_public_members_must_be_lower_case.severity = warning
+dotnet_naming_rule.non_public_members_must_be_lower_case.symbols = non_public_symbols
+dotnet_naming_rule.non_public_members_must_be_lower_case.style = all_lower_case_style
+
+# CSharp code style settings:
+[*.cs]
+# Do not prefer "var" everywhere
+csharp_style_var_for_built_in_types = true:error
+csharp_style_var_when_type_is_apparent = true:error
+csharp_style_var_elsewhere = true:error
+
+# Prefer method-like constructs to have a block body
+csharp_style_expression_bodied_methods = true:suggestion
+csharp_style_expression_bodied_constructors = true:suggestion
+csharp_style_expression_bodied_operators = true:suggestion
+
+# Prefer property-like constructs to have an expression-body
+csharp_style_expression_bodied_properties = true:suggestion
+csharp_style_expression_bodied_indexers = true:suggestion
+csharp_style_expression_bodied_accessors = true:suggestion
+
+# Suggest more modern language features when available
+csharp_style_pattern_matching_over_is_with_cast_check = true:suggestion
+csharp_style_pattern_matching_over_as_with_null_check = true:suggestion
+csharp_style_inlined_variable_declaration = true:suggestion
+csharp_style_throw_expression = true:suggestion
+csharp_style_conditional_delegate_call = true:suggestion
+
+# Newline settings
+csharp_new_line_before_open_brace = all
+csharp_new_line_before_else = true
+csharp_new_line_before_catch = true
+csharp_new_line_before_finally = true
+csharp_new_line_before_members_in_object_initializers = true
+csharp_new_line_before_members_in_anonymous_types = true
+

Diff for: .gitattributes

@@ -0,0 +1,67 @@
+###############################################################################
+# Set default behavior to automatically normalize line endings.
+###############################################################################
+* text=auto
+
+###############################################################################
+# Set default behavior for command prompt diff.
+#
+# This is need for earlier builds of msysgit that does not have it on by
+# default for csharp files.
+# Note: This is only used by command line
+###############################################################################
+#*.cs     diff=csharp
+
+###############################################################################
+# Set the merge driver for project and solution files
+#
+# Merging from the command prompt will add diff markers to the files if there
+# are conflicts (Merging from VS is not affected by the settings below, in VS
+# the diff markers are never inserted). Diff markers may cause the following 
+# file extensions to fail to load in VS. An alternative would be to treat
+# these files as binary and thus will always conflict and require user
+# intervention with every merge. To do so, just uncomment the entries below
+###############################################################################
+#*.sln       merge=binary
+#*.csproj    merge=binary
+#*.vbproj    merge=binary
+#*.vcxproj   merge=binary
+#*.vcproj    merge=binary
+#*.dbproj    merge=binary
+#*.fsproj    merge=binary
+#*.lsproj    merge=binary
+#*.wixproj   merge=binary
+#*.modelproj merge=binary
+#*.sqlproj   merge=binary
+#*.wwaproj   merge=binary
+
+###############################################################################
+# behavior for image files
+#
+# image files are treated as binary by default.
+###############################################################################
+#*.jpg   binary
+#*.png   binary
+#*.gif   binary
+
+###############################################################################
+# diff behavior for common document formats
+# 
+# Convert binary document formats to text before diffing them. This feature
+# is only available from the command line. Turn it on by uncommenting the 
+# entries below.
+###############################################################################
+#*.doc   diff=astextplain
+#*.DOC   diff=astextplain
+#*.docx  diff=astextplain
+#*.DOCX  diff=astextplain
+#*.dot   diff=astextplain
+#*.DOT   diff=astextplain
+#*.pdf   diff=astextplain
+#*.PDF   diff=astextplain
+#*.rtf   diff=astextplain
+#*.RTF   diff=astextplain
+
+# Force bash scripts to always use lf line endings so that if a repo is accessed
+# in Unix via a file share from Windows, the scripts will work.
+*.sh text eol=lf

Diff for: CODE_OF_CONDUCT.md

@@ -0,0 +1,3 @@
+# Code of Conduct
+
+This project has adopted the [Microsoft Open Source Code of Conduct](https://opensource.microsoft.com/codeofconduct/). For more information see the [Code of Conduct FAQ](https://opensource.microsoft.com/codeofconduct/faq/) or contact [[email protected]](mailto:[email protected]) with any additional questions or comments.

Diff for: CodeStyles.targets

@@ -0,0 +1,14 @@
+<?xml version="1.0" encoding="utf-8"?>
+<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
+
+  <PropertyGroup>
+    <CodeAnalysisRuleSet>$(MSBuildThisFileDirectory)Toolkit.ruleset</CodeAnalysisRuleSet>
+    <TreatWarningsAsErrors>true</TreatWarningsAsErrors>
+  </PropertyGroup>
+
+  <ItemGroup>
+    <PackageReference Include="StyleCop.Analyzers" Version="1.1.0-beta006" PrivateAssets="All" />
+    <AdditionalFiles Include="$(MSBuildThisFileDirectory)stylecop.json" InProject="false" />
+  </ItemGroup>
+
+</Project>

Diff for: Contributing.md

@@ -1,69 +1,69 @@
-# Contributing to Xamarin Community Toolkit
+# Contributing
 
-The foundation of **Xamarin Community Toolkit** is simplicity and follow similar practices from the [UWP Community Toolkit](https://github.com/Microsoft/UWPCommunityToolkit).
+Thanks you for your interest in contributing to Xamarin Community Toolkit! In this document we'll outline what you need to know about contributing and how to get started.
 
-A developer should be able to quickly and easily learn to use the API. 
+## Code of Conduct
 
-Simplicity and a low barrier to entry are must-have features of every API. If you have any second thoughts about the complexity of a design, it is almost always much better to cut the feature from the current release and spend more time to get the design right for the next release. 
+Please see our [Code of Conduct](CODE_OF_CONDUCT.md).
 
-You can always add to an API, you cannot ever remove anything from one. If the design does not feel right, and you ship it anyway, you are likely to regret having done so.
+## Prerequisite
 
-That's why many of the guidelines of this document are obvious and serve only one purpose: Simplicity.
+You will need to complete a Contribution License Agreement before any pull request can be accepted. Complete the CLA at https://cla2.dotnetfoundation.org/.
 
-## A good pull request
-Every contribution has to come with:
 
-* Before starting coding, **you should open an issue** and start discussing with the community to see if your idea/feature is interesting enough.
-* A documentation page in the [documentation folder](docs/). Once validated your documentation will be visible [here](http://formscommunitytoolkit.readthedocs.io/en/latest/).
-* A sample for the [Sample app]() (If applicable).
-* Unit tests (If applicable).
-* You tested your code with latest stable brandch of Xamarin and UWP SDK 10586 and SDK 14393.
-* PR has to target dev branch.
+## Documentation - mdoc
 
-PR has to be validated by at least two core members before being merged.
+This project uses [mdoc](http://www.mono-project.com/docs/tools+libraries/tools/monodoc/generating-documentation/) to document types, members, and to add small code snippets and examples.  mdoc files are simple xml files and there is an msbuild target you can invoke to help generate the xml placeholders.
 
-Once merged, you can get a pre-release package of the toolkit be adding the appveyor [NuGet feed](https://ci.appveyor.com/nuget/formscommunitytoolkit).
+Read the [Documenting your code with mdoc wiki page](wiki/Documenting-your-code-with-mdoc) for more information on this process.
 
-## Quality insurance for pull requests for controls
-We encourage developers to follow the following guidances when submitting pull requests for controls:
- * Your control must be usable and efficient with keyboard only.
- * Tab order must be logical.
- * Focused controls must be visible.
- * Action must be triggered when hitting Enter key.
- * Do not use custom colors but instead rely on theme colors so high contrasts themes can be used with your control.
- * Add AutomationProperties.Name on all controls to define what the controls purpose (Name is minimum, but there are some other things too that can really help the screen reader). 
- * Don't use the same Name on two different elements unless they have different control types.
+Every pull request which affects public types or members should include corresponding mdoc xml file changes.
 
-You can find more information about these topics [here](https://blogs.msdn.microsoft.com/winuiautomation/2015/07/14/building-accessible-windows-universal-apps-introduction)
 
-This is to help as part of our effort to build an accessible toolkit.
+### Bug Fixes
 
-## General rules
+If you're looking for something to fix, please browse [open issues](https://github.com/xamarin/XamarinCommunityToolkit/issues). 
 
-* 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 ensure that APIs are intuitive and can be successfully used in basic scenarios without referring to the reference documentation.
-* 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 NOT use regions. DO use partial classes instead.
-* DO declare static dependency properties at the top of their file.
-* DO NOT seal controls.
-* DO use extension methods over static methods where possible.
-* DO NOT return true or false to give sucess status. Throw exceptions if there was a failure.
-* DO use verbs like GET.
-* DO NOT use verbs that are not already used like fetch.
+Follow the style used by the [.NET Foundation](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/coding-style.md), with two primary exceptions:
 
-## Naming conventions
-* We are following the coding guidelines of [.NET Core Foundational libraries](https://github.com/dotnet/corefx/blob/master/Documentation/coding-guidelines/coding-style.md). 
+- We do not use the `private` keyword as it is the default accessibility level in C#.
+- We will **not** use `_` or `s_` as a prefix for internal or private field names
+- We will use `camelCaseFieldName` for naming internal or private fields in both instance and static implementations
 
-## 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.
+Read and follow our [Pull Request template](https://github.com/xamarin/XamarinCommunityToolkit/blob/master/PULL_REQUEST_TEMPLATE.md)
 
-## Files and folders
-* DO associate no more than one class per file.
-* DO use folders to group classes based on features.
+### Proposals
+
+To propose a change or new feature, review the guidance below and then [open an issue using this template](https://github.com/xamarin/XamarinCommunityToolkit/issues/new).
+
+#### Non-Starter Topics
+The following topics should generally not be proposed for discussion as they are non-starters:
+
+* Large renames of APIs
+* Large non-backward-compatible breaking changes
+* Platform-Specifics which can be accomplished without changing Xamarin Community Toolkit
+* Avoid clutter posts like "+1" which do not serve to further the conversation
+
+#### Proposal States
+##### Open
+Open proposals are still under discussion. Please leave your concrete, constructive feedback on this proposal. +1s and other clutter posts which do not add to the discussion will be removed.
+
+##### Accepted
+Accepted proposals are proposals that both the community and core XamarinCommunityToolkit agree should be a part of XamarinCommunityToolkit. These proposals are ready for implementation, but do not yet have a developer actively working on them. These proposals are available for anyone to work on, both community and the core XamarinCommunityToolkit team.
+
+If you wish to start working on an accepted proposal, please reply to the thread so we can mark you as the implementor and change the title to In Progress. This helps to avoid multiple people working on the same thing. If you decide to work on this proposal publicly, feel free to post a link to the branch as well for folks to follow along.
+
+###### What "Accepted" does mean
+* Any community member is welcome to work on the idea.
+* The core XamarinCommunityToolkit team _may_ consider working on this idea on their own, but has not done so until it is marked "In Progress" with a team member assigned as the implementor.
+* Any pull request implementing the proposal will be welcomed with an API and code review.
+
+###### What "Accepted" does not mean
+* The proposal will ever be implemented, either by a community member or by the core XamarinCommunityToolkit team.
+* The core XamarinCommunityToolkit team is committing to implementing a proposal, even if nobody else does. Accepted proposals simply mean that the core XamarinCommunityToolkit team and the community agree that this proposal should be a part of XamarinCommunityToolkit.
+
+##### In Progress
+Once a developer has begun work on a proposal, either from the core XamarinCommunityToolkit team or a community member, the proposal is marked as in progress with the implementors name and (possibly) a link to a development branch to follow along with progress.
+
+#### Rejected
+Rejected proposals will not be implemented or merged into XamarinCommunityToolkit. Once a proposal is rejected, the thread will be closed and the conversation is considered completed, pending considerable new information or changes.