chore: reformat repository with dprint (#370)

* chore: reformat repository with dprint
* ci: change action name to reflect that it's not only markdown
* fix: broken link

.github/workflows/lint.yml

@@ -1,4 +1,4 @@
-name: Lint Markdown
+name: Lint with dprint
 
 on:
   push:

.github/workflows/url-check-config.json

@@ -1,7 +1,7 @@
 {
-  "ignorePatterns": [
-    {
-      "pattern": "^(http|https)://crates.io/"
-    }
-  ]
+    "ignorePatterns": [
+        {
+            "pattern": "^(http|https)://crates.io/"
+        }
+    ]
 }

.gitignore

@@ -1,3 +1,4 @@
 # Generated output of mdbook
 /book
 .DS_Store
+.vscode/settings.json

CONTRIBUTING.md

@@ -2,23 +2,23 @@
 
 ## Introduction
 
-This book is a catalogue of Rust programming techniques, (anti-)patterns,
-idioms and other explanations. It is a compilation of collective (sometimes
-implicit) knowledge as well as experiences that have emerged through
-collaborative work.
+This book is a catalogue of Rust programming techniques, (anti-)patterns, idioms
+and other explanations. It is a compilation of collective (sometimes implicit)
+knowledge as well as experiences that have emerged through collaborative work.
 
-The patterns described here are **not rules**, but should be taken as
-guidelines for writing idiomatic code in Rust. We are collecting Rust patterns
-in this book so people can learn the tradeoffs between Rust idioms and use them
-properly in their own code.
+The patterns described here are **not rules**, but should be taken as guidelines
+for writing idiomatic code in Rust. We are collecting Rust patterns in this book
+so people can learn the tradeoffs between Rust idioms and use them properly in
+their own code.
 
 If you want to be part of this effort here are some ways you can participate:
 
 ## Discussion board
 
 If you have a question or an idea regarding certain content, but you want to
 have feedback of fellow community members, and you think it may not be
-appropriate to file an issue open a discussion in our [discussion board](https://github.com/rust-unofficial/patterns/discussions).
+appropriate to file an issue open a discussion in our
+[discussion board](https://github.com/rust-unofficial/patterns/discussions).
 
 ## Writing a new article
 
@@ -30,11 +30,13 @@ there is an existing discussion or if someone is already working on that topic:
 - [Pull Requests](https://github.com/rust-unofficial/patterns/pulls)
 
 If you don't find an issue regarding your topic, and you are sure it is not more
-feasible to open a thread in the [discussion board](https://github.com/rust-unofficial/patterns/discussions)
-please open a new issue, so we can discuss the ideas and future content
-of the article together and maybe give some feedback/input on it.
+feasible to open a thread in the
+[discussion board](https://github.com/rust-unofficial/patterns/discussions)
+please open a new issue, so we can discuss the ideas and future content of the
+article together and maybe give some feedback/input on it.
 
-When writing a new article it's recommended to copy the [pattern template](https://github.com/rust-unofficial/patterns/blob/master/template.md)
+When writing a new article it's recommended to copy the
+[pattern template](https://github.com/rust-unofficial/patterns/blob/master/template.md)
 into the appropriate directory and start editing it. You may not want to fill
 out every section and remove it, or you might want to add extra sections.
 
@@ -43,12 +45,13 @@ Consider writing your article in a way that has a low barrier of entry so also
 the thought process behind it. So we can encourage people to use these patterns
 early on.
 
-We encourage you to write idiomatic Rust code that builds in the [playground](https://play.rust-lang.org/).
+We encourage you to write idiomatic Rust code that builds in the
+[playground](https://play.rust-lang.org/).
 
 If you use links to blogposts or in general content that is not to be sure
 existing in a few years (e.g. pdfs) please take a snapshot with the
-[Wayback Machine](https://web.archive.org/) and use the link to that snapshot
-in your article.
+[Wayback Machine](https://web.archive.org/) and use the link to that snapshot in
+your article.
 
 Don't forget to add your new article to the `SUMMARY.md` to let it be rendered
 to the book.
@@ -60,8 +63,10 @@ give early feedback (see the following section).
 
 In order to have a consistent style across the book, we suggest to:
 
-- Follow the official Rust book's [style guide](https://github.com/rust-lang/book/blob/master/style-guide.md).
-- Follow [RFC 1574](https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md#appendix-a-full-conventions-text).
+- Follow the official Rust book's
+  [style guide](https://github.com/rust-lang/book/blob/master/style-guide.md).
+- Follow
+  [RFC 1574](https://github.com/rust-lang/rfcs/blob/master/text/1574-more-api-documentation-conventions.md#appendix-a-full-conventions-text).
   Tl;dr:
   - Prefer full types name. For example `Option<T>` instead of `Option`.
   - Prefer line comments (`//`) over block comments (`/* */`) where applicable.
@@ -73,10 +78,11 @@ the book builds and `mdbook test` to make sure that code examples are correct.
 
 ### Markdown lint
 
-To make sure the files comply with our Markdown style we use [markdownlint-cli](https://github.com/igorshubovych/markdownlint-cli).
-To spare you some manual work to get through the CI test you can use the
-following commands to automatically fix most of the emerging problems when
-writing Markdown files.
+To make sure the files comply with our Markdown style we use
+[markdownlint-cli](https://github.com/igorshubovych/markdownlint-cli). To spare
+you some manual work to get through the CI test you can use the following
+commands to automatically fix most of the emerging problems when writing
+Markdown files.
 
 - Install:
 
@@ -96,8 +102,8 @@ writing Markdown files.
 
 "Release early and often!" also applies to pull requests!
 
-Once your article has some visible work, create a `[WIP]` draft pull request
-and give it a description of what you did or want to do. Early reviews of the
+Once your article has some visible work, create a `[WIP]` draft pull request and
+give it a description of what you did or want to do. Early reviews of the
 community are not meant as an offense but to give feedback.
 
 A good principle: "Work together, share ideas, teach others."

README.md

@@ -6,22 +6,24 @@ language that you can read [here](https://rust-unofficial.github.io/patterns/).
 ## Contributing
 
 You are missing content in this repository that can be helpful for others, and
-you are eager to explain it? Awesome! We are always happy about new contributions
-(e.g. elaboration or corrections on certain topics) to this project.
+you are eager to explain it? Awesome! We are always happy about new
+contributions (e.g. elaboration or corrections on certain topics) to this
+project.
 
-You can check the [Umbrella issue](https://github.com/rust-unofficial/patterns/issues/116)
-for all the patterns, anti-patterns, and idioms that could be added.
+You can check the
+[Umbrella issue](https://github.com/rust-unofficial/patterns/issues/116) for all
+the patterns, anti-patterns, and idioms that could be added.
 
-We suggest reading our [Contribution guide](./CONTRIBUTING.md) to get more information
-on how contributing to this repository works.
+We suggest reading our [Contribution guide](./CONTRIBUTING.md) to get more
+information on how contributing to this repository works.
 
 ## Building with mdbook
 
 This book is built with [mdbook](https://rust-lang.github.io/mdBook/). You can
 install it by running `cargo install mdbook`.
 
-If you want to build it locally you can run one of these two commands in the root
-directory of the repository:
+If you want to build it locally you can run one of these two commands in the
+root directory of the repository:
 
 - `mdbook build`
 
@@ -35,4 +37,5 @@ directory of the repository:
 
 ## License
 
-The content of this repository is licensed under **MPL-2.0**; see [LICENSE](./LICENSE).
+The content of this repository is licensed under **MPL-2.0**; see
+[LICENSE](./LICENSE).

dprint.json

@@ -1,11 +1,29 @@
 {
-  "lineWidth": 80,
-  "markdown": {},
-  "includes": [
-    "**/*.{md}"
-  ],
-  "excludes": [],
-  "plugins": [
-    "https://plugins.dprint.dev/markdown-0.15.2.wasm"
-  ]
-}
+    "lineWidth": 80,
+    "markdown": {
+        "lineWidth": 80,
+        "emphasisKind": "asterisks",
+        "strongKind": "asterisks",
+        "textWrap": "always"
+    },
+    "toml": {
+        "lineWidth": 80
+    },
+    "json": {
+        "lineWidth": 80,
+        "indentWidth": 4
+    },
+    "includes": [
+        "**/*.{md}",
+        "**/*.{toml}",
+        "**/*.{json}"
+    ],
+    "excludes": [
+        "target/**/*"
+    ],
+    "plugins": [
+        "https://plugins.dprint.dev/markdown-0.15.2.wasm",
+        "https://plugins.dprint.dev/toml-0.5.4.wasm",
+        "https://plugins.dprint.dev/json-0.17.4.wasm"
+    ]
+}

src/additional_resources/design-principles.md

@@ -7,8 +7,8 @@
 ## [SOLID](https://en.wikipedia.org/wiki/SOLID)
 
 - [Single Responsibility Principle (SRP)](https://en.wikipedia.org/wiki/Single-responsibility_principle):
-  A class should only have a single responsibility, that is, only changes to
-  one part of the software's specification should be able to affect the
+  A class should only have a single responsibility, that is, only changes to one
+  part of the software's specification should be able to affect the
   specification of the class.
 - [Open/Closed Principle (OCP)](https://en.wikipedia.org/wiki/Open%E2%80%93closed_principle):
   "Software entities ... should be open for extension, but closed for
@@ -30,8 +30,8 @@ representation within a system"
 ## [KISS principle](https://en.wikipedia.org/wiki/KISS_principle)
 
 most systems work best if they are kept simple rather than made complicated;
-therefore, simplicity should be a key goal in design, and unnecessary
-complexity should be avoided
+therefore, simplicity should be a key goal in design, and unnecessary complexity
+should be avoided
 
 ## [Law of Demeter (LoD)](https://en.wikipedia.org/wiki/Law_of_Demeter)
 
@@ -54,14 +54,14 @@ unauthorized parties' direct access to them.
 
 ## [Command-Query-Separation(CQS)](https://en.wikipedia.org/wiki/Command%E2%80%93query_separation)
 
-“Functions should not produce abstract side effects...only commands
-(procedures) will be permitted to produce side effects.” - Bertrand Meyer:
-Object-Oriented Software Construction
+“Functions should not produce abstract side effects...only commands (procedures)
+will be permitted to produce side effects.” - Bertrand Meyer: Object-Oriented
+Software Construction
 
 ## [Principle of least astonishment (POLA)](https://en.wikipedia.org/wiki/Principle_of_least_astonishment)
 
-a component of a system should behave in a way that most users will expect it
-to behave. The behavior should not astonish or surprise users
+a component of a system should behave in a way that most users will expect it to
+behave. The behavior should not astonish or surprise users
 
 ## Linguistic-Modular-Units
 
@@ -70,8 +70,8 @@ Meyer: Object-Oriented Software Construction
 
 ## Self-Documentation
 
-“The designer of a module should strive to make all information about the
-module part of the module itself.” - Bertrand Meyer: Object-Oriented Software
+“The designer of a module should strive to make all information about the module
+part of the module itself.” - Bertrand Meyer: Object-Oriented Software
 Construction
 
 ## Uniform-Access
@@ -82,14 +82,13 @@ through computation.” - Bertrand Meyer: Object-Oriented Software Construction
 
 ## Single-Choice
 
-“Whenever a software system must support a set of alternatives, one and only
-one module in the system should know their exhaustive list.” - Bertrand Meyer:
+“Whenever a software system must support a set of alternatives, one and only one
+module in the system should know their exhaustive list.” - Bertrand Meyer:
 Object-Oriented Software Construction
 
 ## Persistence-Closure
 
 “Whenever a storage mechanism stores an object, it must store with it the
-dependents of that object. Whenever a retrieval mechanism retrieves a
-previously stored object, it must also retrieve any dependent of that object
-that has not yet been retrieved.” - Bertrand Meyer: Object-Oriented Software
-Construction
+dependents of that object. Whenever a retrieval mechanism retrieves a previously
+stored object, it must also retrieve any dependent of that object that has not
+yet been retrieved.” - Bertrand Meyer: Object-Oriented Software Construction

src/anti_patterns/borrow_clone.md

@@ -39,31 +39,35 @@ There are special cases -- `Rc<T>` is designed to handle clones intelligently.
 It internally manages exactly one copy of the data, and cloning it will only
 clone the reference.
 
-There is also `Arc<T>` which provides shared ownership of a value of type T
-that is allocated in the heap. Invoking `.clone()` on `Arc` produces a new `Arc`
+There is also `Arc<T>` which provides shared ownership of a value of type T that
+is allocated in the heap. Invoking `.clone()` on `Arc` produces a new `Arc`
 instance, which points to the same allocation on the heap as the source `Arc`,
 while increasing a reference count.
 
 In general, clones should be deliberate, with full understanding of the
 consequences. If a clone is used to make a borrow checker error disappear,
 that's a good indication this anti-pattern may be in use.
 
-Even though `.clone()` is an indication of a bad pattern, sometimes
-**it is fine to write inefficient code**, in cases such as when:
+Even though `.clone()` is an indication of a bad pattern, sometimes **it is fine
+to write inefficient code**, in cases such as when:
 
 - the developer is still new to ownership
-- the code doesn't have great speed or memory constraints
-  (like hackathon projects or prototypes)
+- the code doesn't have great speed or memory constraints (like hackathon
+  projects or prototypes)
 - satisfying the borrow checker is really complicated, and you prefer to
   optimize readability over performance
 
-If an unnecessary clone is suspected, The [Rust Book's chapter on Ownership](https://doc.rust-lang.org/book/ownership.html)
-should be understood fully before assessing whether the clone is required or not.
+If an unnecessary clone is suspected, The
+[Rust Book's chapter on Ownership](https://doc.rust-lang.org/book/ownership.html)
+should be understood fully before assessing whether the clone is required or
+not.
 
-Also be sure to always run `cargo clippy` in your project, which will detect some
-cases in which `.clone()` is not necessary, like [1](https://rust-lang.github.io/rust-clippy/master/index.html#redundant_clone),
+Also be sure to always run `cargo clippy` in your project, which will detect
+some cases in which `.clone()` is not necessary, like
+[1](https://rust-lang.github.io/rust-clippy/master/index.html#redundant_clone),
 [2](https://rust-lang.github.io/rust-clippy/master/index.html#clone_on_copy),
-[3](https://rust-lang.github.io/rust-clippy/master/index.html#map_clone) or [4](https://rust-lang.github.io/rust-clippy/master/index.html#clone_double_ref).
+[3](https://rust-lang.github.io/rust-clippy/master/index.html#map_clone) or
+[4](https://rust-lang.github.io/rust-clippy/master/index.html#clone_double_ref).
 
 ## See also
 

src/anti_patterns/deny-warnings.md

@@ -53,8 +53,9 @@ This can be done by any individual developer (or be set in a CI tool like
 Travis, but remember that this may break the build when something changes)
 without requiring a change to the code.
 
-Alternatively, we can specify the lints that we want to `deny` in the code.
-Here is a list of warning lints that is (hopefully) safe to deny (as of Rustc 1.48.0):
+Alternatively, we can specify the lints that we want to `deny` in the code. Here
+is a list of warning lints that is (hopefully) safe to deny (as of Rustc
+1.48.0):
 
 ```rust,ignore
 #![deny(bad_style,

src/anti_patterns/deref.md

@@ -107,7 +107,8 @@ dispatch to `Foo` manually. We do intend to add a mechanism for inheritance
 similar to this to Rust, but it is likely to be some time before it reaches
 stable Rust. See these [blog](http://aturon.github.io/blog/2015/09/18/reuse/)
 [posts](http://smallcultfollowing.com/babysteps/blog/2015/10/08/virtual-structs-part-4-extended-enums-and-thin-traits/)
-and this [RFC issue](https://github.com/rust-lang/rfcs/issues/349) for more details.
+and this [RFC issue](https://github.com/rust-lang/rfcs/issues/349) for more
+details.
 
 The `Deref` trait is designed for the implementation of custom pointer types.
 The intention is that it will take a pointer-to-`T` to a `T`, not convert
@@ -123,6 +124,7 @@ conversion between arbitrary types.
 ## See also
 
 - [Collections are smart pointers idiom](../idioms/deref.md).
-- Delegation crates for less boilerplate like [delegate](https://crates.io/crates/delegate)
-  or [ambassador](https://crates.io/crates/ambassador)
+- Delegation crates for less boilerplate like
+  [delegate](https://crates.io/crates/delegate) or
+  [ambassador](https://crates.io/crates/ambassador)
 - [Documentation for `Deref` trait](https://doc.rust-lang.org/std/ops/trait.Deref.html).

src/anti_patterns/index.md

@@ -1,8 +1,8 @@
 # Anti-patterns
 
-An [anti-pattern](https://en.wikipedia.org/wiki/Anti-pattern) is a solution to
-a "recurring problem that is usually ineffective and risks being highly
+An [anti-pattern](https://en.wikipedia.org/wiki/Anti-pattern) is a solution to a
+"recurring problem that is usually ineffective and risks being highly
 counterproductive". Just as valuable as knowing how to solve a problem, is
-knowing how _not_ to solve it. Anti-patterns give us great counter-examples to
+knowing how *not* to solve it. Anti-patterns give us great counter-examples to
 consider relative to design patterns. Anti-patterns are not confined to code.
 For example, a process can be an anti-pattern, too.