Correct white-space in documentation

fluentassertions · Aug 20, 2021 · 75bfd96 · 75bfd96
1 parent 956eaa5
commit 75bfd96
Show file tree

Hide file tree

Showing 10 changed files with 16 additions and 12 deletions.
diff --git a/docs/.markdownlint.yml b/docs/.markdownlint.yml
@@ -0,0 +1,8 @@
+default: true
+
+MD013:
+  false
+
+MD024:
+  # Only check sibling headings
+  siblings_only: true
diff --git a/docs/_pages/basicassertions.md b/docs/_pages/basicassertions.md
@@ -27,7 +27,7 @@ someObject.Should().BeOfType<Exception>()
   .Which.Message.Should().Be("Other Message");
 ```
 
-To assert that two objects are equal (through their implementation of `Object.Equals`), use 
+To assert that two objects are equal (through their implementation of `Object.Equals`), use
 
 ```csharp
 string otherObject = "whatever";

diff --git a/docs/_pages/eventmonitoring.md b/docs/_pages/eventmonitoring.md
@@ -32,7 +32,7 @@ monitoredSubject
 `WithSender()` will verify that all occurrences of the event had their `sender` argument set to the specified object.
 `WithArgs()` just verifies that at least one occurrence had a matching `EventArgs` object. Both will return an `IEventRecording` representing only the events that match the constraint.
 
-This means that event monitoring only works for events that comply with the standard two-argument `sender`/`args` .NET pattern. 
+This means that event monitoring only works for events that comply with the standard two-argument `sender`/`args` .NET pattern.
 
 Since verifying for `PropertyChanged` events is so common, we've included a specialized shortcut to the example above:
 

diff --git a/docs/_pages/exceptions.md b/docs/_pages/exceptions.md
@@ -84,7 +84,6 @@ act.Should().NotThrowAfter(10.Seconds(), 100.Milliseconds());
 
 The second argument of `NotThrowAfter` specifies the time that should pass before `act` is executed again after an execution which threw an exception.
 
-
 If the method you are testing returns an `IEnumerable` or `IEnumerable<T>` and it uses the `yield` keyword to construct that collection, just calling the method will not cause the effect you expected because the real work is not done until you actually iterate over that collection. You can use the `Enumerating()` extension method to force enumerating the collection like this.
 
 ```csharp

diff --git a/docs/_pages/extensibility.md b/docs/_pages/extensibility.md
@@ -5,7 +5,6 @@ toc: true
 layout: single
 sidebar:
   nav: "sidebar"
-
 ---
 
 To facilitate the need for those developers which ideas don't end up in the library, Fluent Assertions offers several extension points. They are there so that they can build their own extensions with the same consistent API and behavior people are used to. And if they feel the need to alter the behavior of the built-in set of assertion methods, they can use the many hooks offered out of the box. The flip side of all of this is that we cannot just change the internals of FA without considering backwards compatibility. But looking at the many extensions available on the NuGet, it's absolutely worth it.
@@ -175,9 +174,9 @@ class EnumerableCustomClassFormatter : EnumerableValueFormatter
 
 ## To be or not to be a value type
 
-The structural equivalency API provided by `Should().BeEquivalentTo` and is arguably the most powerful, but also the most complicated part of Fluent Assertions. And to make things worse, you can extend and adapt the default behavior quite extensively. 
+The structural equivalency API provided by `Should().BeEquivalentTo` and is arguably the most powerful, but also the most complicated part of Fluent Assertions. And to make things worse, you can extend and adapt the default behavior quite extensively.
 
-For instance, to determine whether FA needs to recursive into a complex object, it needs to know whether or not a particular type has value semantics. An object that has properties isn't necessarily a complex type that you want to recurse on. `DirectoryInfo` has properties, but you don't want FA to just traverse its properties. So you need to tell what types should be treated as value types. 
+For instance, to determine whether FA needs to recursive into a complex object, it needs to know whether or not a particular type has value semantics. An object that has properties isn't necessarily a complex type that you want to recurse on. `DirectoryInfo` has properties, but you don't want FA to just traverse its properties. So you need to tell what types should be treated as value types.
 
 The default behavior is to treat every type that overrides `Object.Equals` as on object that was designed to have value semantics. Unfortunately, anonymous types and tuples also override this method, but because we tend to use them quite often in equivalency comparison, we always compare them by their properties.
 

diff --git a/docs/_pages/introduction.md b/docs/_pages/introduction.md
@@ -149,4 +149,3 @@ Expected string to be "Expected" with a length of 8, but "Actual" has a length o
 ```
 
 For more information take a look at the [AssertionScopeSpecs.cs](https://github.com/fluentassertions/fluentassertions/blob/master/Tests/Shared.Specs/AssertionScopeSpecs.cs) in Unit Tests.
-
diff --git a/docs/_pages/releases.md b/docs/_pages/releases.md
@@ -122,8 +122,8 @@ sidebar:
 * Made `EquivalencyAssertionOptionsExtentions` `internal` (and fixed a typo in the type name) - [#1221](https://github.com/fluentassertions/fluentassertions/pull/1221).
 * Changed `ReferenceTypeAssertions.Subject` to be `readonly` - [#1229](https://github.com/fluentassertions/fluentassertions/pull/1229).
   * Set the `Subject` through the constructor instead.
-* Changed `TypeAssertions.HaveAccessModifier` return type from `AndConstraint<Type> ` to `AndConstraint<TypeAssertions>` - [#1159](https://github.com/fluentassertions/fluentassertions/pull/1159).
-* Changed `TypeAssertions.NotHaveAccessModifier` return type from `AndConstraint<Type> ` to `AndConstraint<TypeAssertions>` - [#1159](https://github.com/fluentassertions/fluentassertions/pull/1159).
+* Changed `TypeAssertions.HaveAccessModifier` return type from `AndConstraint<Type>` to `AndConstraint<TypeAssertions>` - [#1159](https://github.com/fluentassertions/fluentassertions/pull/1159).
+* Changed `TypeAssertions.NotHaveAccessModifier` return type from `AndConstraint<Type>` to `AndConstraint<TypeAssertions>` - [#1159](https://github.com/fluentassertions/fluentassertions/pull/1159).
 * Changed `AllBeAssignableTo<T>` and `AllBeOfType<T>` return type from `AndConstraint<TAssertions>` to `AndWhichConstraint<TAssertions, IEnumerable<T>>` - [#1265](https://github.com/fluentassertions/fluentassertions/pull/1265).
 * The new extension on `TaskCompletionSource<T>` overlays the previously used assertions based on `ObjectAssertions`.
 * Removed `[Not]BeCloseTo` for `DateTime[Offset]` and `TimeSpan` that took an `int precision` - [#1278](https://github.com/fluentassertions/fluentassertions/pull/1278).

diff --git a/docs/_pages/tips.md b/docs/_pages/tips.md
@@ -19,7 +19,6 @@ The examples below show how you might improve your existing assertions to both g
 
 If you see something missing, please consider submitting a pull request.
 
-
 {% include assertion-comparison.html header1="Assertion" header2="Improvement" caption="Collections"               examples=site.data.tips.collections %}
 {% include assertion-comparison.html header1="Assertion" header2="Improvement" caption="Comparable and Numerics"   examples=site.data.tips.comparable %}
 {% include assertion-comparison.html header1="Assertion" header2="Improvement" caption="DateTimes"                 examples=site.data.tips.datetimes %}

diff --git a/docs/_pages/typesandmethods.md b/docs/_pages/typesandmethods.md
@@ -125,4 +125,4 @@ AllTypes.From(assembly)
   .ThatAreNotInNamespace("Internal.Main.Test");
 ```
 
-There are so many possibilities and specialized methods that none of these examples do them good. Check out the [TypeAssertionSpecs.cs](https://github.com/fluentassertions/fluentassertions/blob/master/Tests/Shared.Specs/TypeAssertionSpecs.cs#L12) from the source for more examples. 
+There are so many possibilities and specialized methods that none of these examples do them good. Check out the [TypeAssertionSpecs.cs](https://github.com/fluentassertions/fluentassertions/blob/master/Tests/Shared.Specs/TypeAssertionSpecs.cs#L12) from the source for more examples.
diff --git a/docs/_pages/upgradingtov6.md b/docs/_pages/upgradingtov6.md
@@ -217,4 +217,4 @@ A case which led to some confusion among our users was that `(2)` changed behavi
 You might ask if we could not just have changed the overload signature from `params object[]` to `params T[]` to solve the type problem while keeping the convient overload.
 The answer is no (as far as we know), as the compiler prefers resolving e.g. `IEnumerable<T>` to `params IEnumerable<T>[]` over `IEnumerable<T>`.
 
-For Fluent Assertions 6.0 the implications of this are that `(1)` no longer compiles, as `BeEquivalentTo` takes an `IEnumerable<T>`, but `(2)` now works as expected.
+For Fluent Assertions 6.0 the implications of this are that `(1)` no longer compiles, as `BeEquivalentTo` takes an `IEnumerable<T>`, but `(2)` now works as expected.