diff --git a/.editorconfig b/.editorconfig
deleted file mode 100644
index 4a4080a..0000000
--- a/.editorconfig
+++ /dev/null
@@ -1,6 +0,0 @@
-[*]
-indent_style = space
-indent_size = 4
-# Config for shfmt
-switch_case_indent = true
-space_redirects = true
diff --git a/.prettierrc.yaml b/.prettierrc.yaml
index f07fbdd..a69b879 100644
--- a/.prettierrc.yaml
+++ b/.prettierrc.yaml
@@ -1,3 +1,7 @@
-tabWidth: 2
+tabWidth: 4
+printWidth: 80
+proseWrap: "always"
 overrides:
-    - { "files": "*.yaml", "options": { "tabWidth": 4 } }
+    - files: "*.md"
+      options:
+          tabWidth: 2
diff --git a/README.md b/README.md
index 2c8077c..4802467 100644
--- a/README.md
+++ b/README.md
@@ -2,8 +2,8 @@
 
 sdbusplus contains two parts:
 
-1. A C++ library (libsdbusplus) for interacting with D-Bus, built on top of
-   the sd-bus library from systemd.
+1. A C++ library (libsdbusplus) for interacting with D-Bus, built on top of the
+   sd-bus library from systemd.
 2. A tool (sdbus++) to generate C++ bindings to simplify the development of
    D-Bus-based applications.
 
@@ -11,8 +11,8 @@
 
 The sdbusplus library requires sd-bus, which is contained in libsystemd.
 
-The sdbus++ application requires Python 3 and the Python libraries mako
-and inflection.
+The sdbus++ application requires Python 3 and the Python libraries mako and
+inflection.
 
 ## Building
 
@@ -29,8 +29,8 @@
 Optionally, building the tests and examples can be disabled by passing
 `-Dtests=disabled` and `-Dexamples=disabled` respectively to `meson`.
 
-The sdbus++ application is installed as a standard Python package
-using `setuptools`.
+The sdbus++ application is installed as a standard Python package using
+`setuptools`.
 
 ```sh
 cd tools
@@ -63,33 +63,33 @@
 ```
 
 In a few, relatively succinct, C++ lines this snippet will create a D-Bus
-connection to the system bus, and call the systemd login manager to get a
-list of active users. The message and bus objects are automatically freed
-when they leave scope and the message format strings are generated at compile
-time based on the types being read. Compare this to the corresponding server
-code within [logind].
+connection to the system bus, and call the systemd login manager to get a list
+of active users. The message and bus objects are automatically freed when they
+leave scope and the message format strings are generated at compile time based
+on the types being read. Compare this to the corresponding server code within
+[logind].
 
 In general, the library attempts to mimic the naming conventions of the sd-bus
 library: ex. `sd_bus_call` becomes `sdbusplus::bus::call`,
 `sd_bus_get_unique_name` becomes `sdbusplus::bus::get_unique_name`,
-`sd_bus_message_get_signature` becomes `sdbusplus::message::get_signature`,
-etc. This allows a relatively straight-forward translation back to the sd-bus
+`sd_bus_message_get_signature` becomes `sdbusplus::message::get_signature`, etc.
+This allows a relatively straight-forward translation back to the sd-bus
 functions for looking up the manpage details.
 
 [sd-bus]: http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html
-[logind]: https://github.com/systemd/systemd/blob/d60c527009133a1ed3d69c14b8c837c790e78d10/src/login/logind-dbus.c#L496
+[logind]:
+  https://github.com/systemd/systemd/blob/d60c527009133a1ed3d69c14b8c837c790e78d10/src/login/logind-dbus.c#L496
 
 ## Binding generation tool
 
-sdbusplus also contains a bindings generator tool: `sdbus++`. The purpose of
-a bindings generator is to reduce the boilerplate associated with creating
-D-Bus server or client applications. When creating a server application,
-rather than creating sd-bus vtables and writing C-style functions to handle
-each vtable callback, you can create a small YAML file to define your D-Bus
-interface and the `sdbus++` tool will create a C++ class that implements your
-D-Bus interface. This class has a set of virtual functions for each method
-and property, which you can overload to create your own customized behavior
-for the interface.
+sdbusplus also contains a bindings generator tool: `sdbus++`. The purpose of a
+bindings generator is to reduce the boilerplate associated with creating D-Bus
+server or client applications. When creating a server application, rather than
+creating sd-bus vtables and writing C-style functions to handle each vtable
+callback, you can create a small YAML file to define your D-Bus interface and
+the `sdbus++` tool will create a C++ class that implements your D-Bus interface.
+This class has a set of virtual functions for each method and property, which
+you can overload to create your own customized behavior for the interface.
 
 There are currently two types of YAML files: [interface](docs/yaml/interface.md)
 and [error](docs/yaml/error.md). Interfaces are used to create server and client
diff --git a/docs/asio.md b/docs/asio.md
index b215d9e..04ff9c1 100644
--- a/docs/asio.md
+++ b/docs/asio.md
@@ -8,18 +8,20 @@
 
 To return a D-Bus error reply for either GetProperty or SetProperty, throw a
 custom exception derived from `sdbusplus::exception_t`. For the custom
-exception, you can return a well-defined org.freedesktop.DBus.Error
-(https://www.freedesktop.org/software/systemd/man/sd-bus-errors.html#) from the
-`name()` or a custom/arbitrary name. The former will be automatically translated
-into a matching error code
-(https://github.com/systemd/systemd/blob/485c9e19e7ebcd912d5fbf11f40afc62951173f8/src/libsystemd/sd-bus/bus-error.c)
-that can be consumed by the caller, while the latter will always be mapped to
-`EIO`, requiring a `strcmp` to determine the exact error name.
+exception, you can return a well-defined [org.freedesktop.DBus.Error][1] from
+the `name()` or a custom/arbitrary name. The former will be automatically
+translated into a matching [error code][2] that can be consumed by the caller,
+while the latter will always be mapped to `EIO`, requiring a `strcmp` to
+determine the exact error name.
 
 The handler may also throw any exception not derived from
 `sdbusplus::exception_t`, in which case a generic
 org.freedesktop.DBus.Error.InvalidArgs error will be returned to the caller.
 
+[1]: https://www.freedesktop.org/software/systemd/man/sd-bus-errors.html#
+[2]:
+  https://github.com/systemd/systemd/blob/485c9e19e7ebcd912d5fbf11f40afc62951173f8/src/libsystemd/sd-bus/bus-error.c
+
 ### Get Property callback
 
 When registering a property using ASIO methods, the get callback should meet the
diff --git a/docs/yaml/error.md b/docs/yaml/error.md
index 4177547..292b0ef 100644
--- a/docs/yaml/error.md
+++ b/docs/yaml/error.md
@@ -1,19 +1,17 @@
 # Error YAML
 
-D-Bus errors can be defined by creating a YAML file to describe the errors.
-From this YAML file, both documentation and binding code may be generated.
-The generated bindings are C++ exception types corresponding to the D-Bus
-error name. Ex. `org.freedesktop.Example.Error.SomeError` will create a
-generated exception type of
-`sdbusplus::org::freedesktop::Example::Error::SomeError` which may be thrown
-or caught as appropriate. If the error is thrown from an interface method
-which has specified it may return that error, then the bindings will generate
-a catch clause that returns a D-Bus error like
+D-Bus errors can be defined by creating a YAML file to describe the errors. From
+this YAML file, both documentation and binding code may be generated. The
+generated bindings are C++ exception types corresponding to the D-Bus error
+name. Ex. `org.freedesktop.Example.Error.SomeError` will create a generated
+exception type of `sdbusplus::org::freedesktop::Example::Error::SomeError` which
+may be thrown or caught as appropriate. If the error is thrown from an interface
+method which has specified it may return that error, then the bindings will
+generate a catch clause that returns a D-Bus error like
 "org.freedesktop.Example.Error.SomeError" to the method caller.
 
-The error YAML is simply a list of `name` along with optional `description`
-and `errno` properties.
-Example:
+The error YAML is simply a list of `name` along with optional `description` and
+`errno` properties. Example:
 
 ```yaml
 - name: SomeError
diff --git a/docs/yaml/interface.md b/docs/yaml/interface.md
index 69ef12d..e5b6e28 100644
--- a/docs/yaml/interface.md
+++ b/docs/yaml/interface.md
@@ -1,16 +1,15 @@
 # Interface YAML
 
-D-Bus interfaces can be defined by creating a YAML file to describe the
-methods, properties, and signals they contain. From this YAML file,
-both documentation and binding code may be generated.
+D-Bus interfaces can be defined by creating a YAML file to describe the methods,
+properties, and signals they contain. From this YAML file, both documentation
+and binding code may be generated.
 
 ## YAML sections
 
 An interface YAML may have the following sections:
 
 - description
-  - A small documentation section describing the purpose of the
-    interface.
+  - A small documentation section describing the purpose of the interface.
 - methods
   - A list of methods provided by this D-Bus interface.
 - properties
@@ -22,33 +21,32 @@
 
 ## Enumerations
 
-A common problem we have found with D-Bus interfaces is having a consistent
-way to define enumerations. Two common practices are to either assign
-special meaning to integers, as a C compiler might do, or to have specific
-strings representing the enumeration name. The
-[D-Bus API design guidelines][dbus-design-guidelines] specify both of these
-options:
+A common problem we have found with D-Bus interfaces is having a consistent way
+to define enumerations. Two common practices are to either assign special
+meaning to integers, as a C compiler might do, or to have specific strings
+representing the enumeration name. The [D-Bus API design
+guidelines][dbus-design-guidelines] specify both of these options:
 
 > For APIs being used in constrained situations, enumerated values should be
-> transmitted as unsigned integers. For APIs which need to be extended by
-> third parties or which are used in more loosely coupled systems, enumerated
-> values should be strings in some defined format.
+> transmitted as unsigned integers. For APIs which need to be extended by third
+> parties or which are used in more loosely coupled systems, enumerated values
+> should be strings in some defined format.
 
 What we have done in `sdbus++` is to consider enumerations as a first-class
-type. Within an interface you can define an enumeration and the bindings
-will have a C++ enumeration defined for it. At a D-Bus level any property or
-method parameter will be a string, but the string will contain a
-fully-qualified name "interface.enum-name.enum-value" like
-"org.freedesktop.Example.Color.Red". Within the generated bindings, an
-automatic conversion is done between strings and C++ enumeration values and
-clients will get an "xyz.openbmc_project.sdbusplus.Error.InvalidEnumString"
-error response if they attempt to use an invalid string value.
+type. Within an interface you can define an enumeration and the bindings will
+have a C++ enumeration defined for it. At a D-Bus level any property or method
+parameter will be a string, but the string will contain a fully-qualified name
+"interface.enum-name.enum-value" like "org.freedesktop.Example.Color.Red".
+Within the generated bindings, an automatic conversion is done between strings
+and C++ enumeration values and clients will get an
+"xyz.openbmc_project.sdbusplus.Error.InvalidEnumString" error response if they
+attempt to use an invalid string value.
 
 An enumeration must have the YAML properties `name` and `values` and may
-optionally contain a `description`. The `name` is a word corresponding to
-the desired "enum-name" portion of the fully-qualified name and the resulting
-C++ enum type. The `values` are a list of enumeration values each containing
-their own `name` and optional `description`.
+optionally contain a `description`. The `name` is a word corresponding to the
+desired "enum-name" portion of the fully-qualified name and the resulting C++
+enum type. The `values` are a list of enumeration values each containing their
+own `name` and optional `description`.
 
 Example:
 
@@ -70,9 +68,9 @@
 
 ### Base types
 
-Types are identified in YAML using their typename found in the
-[D-Bus specification][dbus-spec], but listed using lowercases: `int64`
-instead of `INT64` or C++ `int64_t`.
+Types are identified in YAML using their typename found in the [D-Bus
+specification][dbus-spec], but listed using lowercases: `int64` instead of
+`INT64` or C++ `int64_t`.
 
 - `byte`
 - `boolean`
@@ -122,8 +120,8 @@
 
 It may seem odd that variants are required to list the types they may contain,
 but this is due to C++ being a strongly-typed language. In order to generate
-bindings, to read from and append to a message, the binding generator must
-know all possible types the variant may contain.
+bindings, to read from and append to a message, the binding generator must know
+all possible types the variant may contain.
 
 ### Enumeration Types
 
@@ -194,12 +192,11 @@
 
 If no flag is given, a property will default to `emits_change`.
 
-Both `const` and `readonly` prevent D-Bus clients from being able to write
-to a property. `const` is a D-Bus indication that the property can never
-change, while `readonly` properties can be changed by the D-Bus server itself.
-As examples, the `Version` property on a software object might be appropriate
-to be `const` and the `Value` property on a sensor object would likely be
-`readonly`.
+Both `const` and `readonly` prevent D-Bus clients from being able to write to a
+property. `const` is a D-Bus indication that the property can never change,
+while `readonly` properties can be changed by the D-Bus server itself. As
+examples, the `Version` property on a software object might be appropriate to be
+`const` and the `Value` property on a sensor object would likely be `readonly`.
 
 Example:
 
@@ -219,8 +216,8 @@
 ## Signals
 
 A signal must have the YAML property `name` and may optionally have a
-`description` and list of `properties`. Properties are specified the same
-as interface properties.
+`description` and list of `properties`. Properties are specified the same as
+interface properties.
 
 Example:
 
diff --git a/example/yaml/net/poettering/Calculator.interface.yaml b/example/yaml/net/poettering/Calculator.interface.yaml
index 543d559..4862f84 100644
--- a/example/yaml/net/poettering/Calculator.interface.yaml
+++ b/example/yaml/net/poettering/Calculator.interface.yaml
@@ -1,6 +1,6 @@
 description: >
-    An example interface originally described as part of the announcement
-    of new sd-bus interfaces at:
+    An example interface originally described as part of the announcement of new
+    sd-bus interfaces at:
         http://0pointer.net/blog/the-new-sd-bus-api-of-systemd.html
 methods:
     - name: Multiply