Add newlines after headings for best practice, trim trailing spaces & convert...

Add newlines after headings for best practice, trim trailing spaces & convert sneaky incorrectly coded chars

blank newline after headins is apparently best practice according to http://stackoverflow.com/q/42953462/1292918

docs/ThrowTheSwitchCodingStandard.md

 # ThrowTheSwitch.org Coding Standard
+
 Hi. Welcome to the coding standard for ThrowTheSwitch.org. For the most part,
 we try to follow these standards to unify our contributors' code into a cohesive
 unit (puns intended). You might find places where these standards aren't
@@ -6,12 +7,16 @@ followed. We're not perfect. Please be polite where
 you notice these discrepancies and we'll try to be polite when we notice yours.
 ;)
 
+
 ## Why Have A Coding Standard?
+
 Being consistent makes code easier to understand. We've made an attempt to keep
 our standard simple because we also believe that we can only expect someone to
 follow something that is understandable. Please do your best.
 
+
 ## Our Philosophy
+
 Before we get into details on syntax, let's take a moment to talk about our
 vision for these tools. We're C developers and embedded software developers.
 These tools are great to test any C code, but catering to embedded software has
@@ -40,7 +45,9 @@ default. We believe that if you're working with a simple compiler and target,
 you shouldn't need to configure very much... we try to make the tools guess as
 much as they can, but give the user the power to override it when it's wrong.
 
+
 ## Naming Things
+
 Let's talk about naming things. Programming is all about naming things. We name
 files, functions, variables, and so much more. While we're not always going to
 find the best name for something, we actually put quite a bit of effort into
@@ -53,12 +60,16 @@ most important to us (but we do all four whenever possible):
 3. Consistent
 4. Memorable
 
+
 #### Readable
+
 We want to read our code. This means we like names and flow that are more
 naturally read. We try to avoid double negatives. We try to avoid cryptic
 abbreviations (sticking to ones we feel are common).
 
+
 #### Descriptive
+
 We like descriptive names for things, especially functions and variables.
 Finding the right name for something is an important endeavor. You might notice
 from poking around our code that this often results in names that are a little
@@ -79,13 +90,17 @@ naming. We find i, j, and k are better loop counters than loopCounterVar or
 whatnot. We only break this rule when we see that more description could improve
 understanding of an algorithm.
 
+
 #### Consistent
+
 We like consistency, but we're not really obsessed with it. We try to name our
 configuration macros in a consistent fashion... you'll notice a repeated use of
 UNITY_EXCLUDE_BLAH or UNITY_USES_BLAH macros. This helps users avoid having to
 remember each macro's details.
 
+
 #### Memorable
+
 Where ever it doesn't violate the above principles, we try to apply memorable
 names. Sometimes this means using something that is simply descriptive, but
 often we strive for descriptive AND unique... we like quirky names that stand
@@ -96,7 +111,9 @@ module in charge of invoking tasks during releases than release_invoker? Don't
 get carried away. The names are still descriptive and fulfill the above
 requirements, but they don't feel stale.
 
+
 ## C and C++ Details
+
 We don't really want to add to the style battles out there. Tabs or spaces?
 How many spaces? Where do the braces go? These are age-old questions that will
 never be answered... or at least not answered in a way that will make everyone
@@ -106,7 +123,9 @@ We've decided on our own style preferences. If you'd like to contribute to these
 projects (and we hope that you do), then we ask if you do your best to follow
 the same. It will only hurt a little. We promise.
 
+
 #### Whitespace
+
 Our C-style is to use spaces and to use 4 of them per indent level. It's a nice
 power-of-2 number that looks decent on a wide screen. We have no more reason
 than that. We break that rule when we have lines that wrap (macros or function
@@ -120,7 +139,9 @@ things up in nice tidy columns.
     }
 ```
 
+
 #### Case
+
 - Files - all lower case with underscores.
 - Variables - all lower case with underscores
 - Macros - all caps with underscores.
@@ -128,7 +149,9 @@ things up in nice tidy columns.
 - Functions - camel cased. Usually named ModuleName_FuncName
 - Constants and Globals - camel cased.
 
+
 #### Braces
+
 The left brace is on the next line after the declaration. The right brace is
 directly below that. Everything in between in indented one level. If you're
 catching an error and you have a one-line, go ahead and to it on the same line.
@@ -140,31 +163,41 @@ catching an error and you have a one-line, go ahead and to it on the same line.
     }
 ```
 
+
 #### Comments
+
 Do you know what we hate? Old-school C block comments. BUT, we're using them
 anyway. As we mentioned, our goal is to support every compiler we can,
 especially embedded compilers. There are STILL C compilers out there that only
 support old-school block comments. So that is what we're using. We apologize. We
 think they are ugly too.
 
+
 ## Ruby Details
+
 Is there really such thing as a Ruby coding standard? Ruby is such a free form
 language, it seems almost sacrilegious to suggest that people should comply to
 one method! We'll keep it really brief!
 
+
 #### Whitespace
+
 Our Ruby style is to use spaces and to use 2 of them per indent level. It's a
 nice power-of-2 number that really grooves with Ruby's compact style. We have no
 more reason than that. We break that rule when we have lines that wrap. When
 that happens, we like to indent further to line things up in nice tidy columns.
 
+
 #### Case
+
 - Files - all lower case with underscores.
 - Variables - all lower case with underscores
 - Classes, Modules, etc - Camel cased.
 - Functions - all lower case with underscores
 - Constants - all upper case with underscores
 
+
 ## Documentation
+
 Egad. Really? We use markdown and we like pdf files because they can be made to
 look nice while still being portable. Good enough?

docs/UnityAssertionsReference.md

 # Unity Assertions Reference
+
 ## Background and Overview
+
 ### Super Condensed Version
+
 - An assertion establishes truth (i.e. boolean True) for a single condition.
 Upon boolean False, an assertion stops execution and reports the failure.
 - Unity is mainly a rich collection of assertions and the support to gather up
@@ -13,14 +16,18 @@ source code in, well, test code.
 - Document types, expected values, and basic behavior in your source code for
 free.
 
+
 ### Unity Is Several Things But Mainly It's Assertions
+
 One way to think of Unity is simply as a rich collection of assertions you can
 use to establish whether your source code behaves the way you think it does.
 Unity provides a framework to easily organize and execute those assertions in
 test code separate from your source code.
 
+
 ### What's an Assertion?
-At their core, assertions are an establishment of truth—boolean truth. Was this 
+
+At their core, assertions are an establishment of truth - boolean truth. Was this
 thing equal to that thing? Does that code doohickey have such-and-such property
 or not? You get the idea. Assertions are executable code (to appreciate the big
 picture on this read up on the difference between
@@ -37,7 +44,9 @@ support, it's far too tempting to litter source code with C's `assert()`'s. It's
 generally much cleaner, manageable, and more useful to separate test and source
 code in the way Unity facilitates.
 
+
 ### Unity's Assertions: Helpful Messages _and_ Free Source Code Documentation
+
 Asserting a simple truth condition is valuable, but using the context of the
 assertion is even more valuable. For instance, if you know you're comparing bit
 flags and not just integers, then why not use that context to give explicit,
@@ -51,8 +60,11 @@ tests pass, you have a detailed, up-to-date view of the intent and mechanisms in
 your source code. And due to a wondrous mystery, well-tested code usually tends
 to be well designed code.
 
+
 ## Assertion Conventions and Configurations
+
 ### Naming and Parameter Conventions
+
 The convention of assertion parameters generally follows this order:
 
     TEST_ASSERT_X( {modifiers}, {expected}, actual, {size/count} )
@@ -73,7 +85,9 @@ is handled by several assertions. The differences among these are in how failure
 messages are presented. For instance, a `_HEX` variant of an assertion prints
 the expected and actual values of that assertion formatted as hexadecimal.
 
+
 #### TEST_ASSERT_X_MESSAGE Variants
+
 _All_ assertions are complemented with a variant that includes a simple string
 message as a final parameter. The string you specify is appended to an assertion
 failure message in Unity output.
@@ -90,7 +104,9 @@ becomes messageified like thus...
 
     TEST_ASSERT_X_MESSAGE( {modifiers}, {expected}, actual, {size/count}, message )
 
+
 #### TEST_ASSERT_X_ARRAY Variants
+
 Unity provides a collection of assertions for arrays containing a variety of
 types. These are documented in the Array section below. These are almost on par
 with the `_MESSAGE`variants of Unity's Asserts in that for pretty much any Unity
@@ -110,24 +126,32 @@ Notes:
 - Assertions for handling arrays of floating point values are grouped with float
 and double assertions (see immediately following section).
 
+
 ### Configuration
+
 #### Floating Point Support Is Optional
+
 Support for floating point types is configurable. That is, by defining the
 appropriate preprocessor symbols, floats and doubles can be individually enabled
 or disabled in Unity code. This is useful for embedded targets with no floating
 point math support (i.e. Unity compiles free of errors for fixed point only
 platforms). See Unity documentation for specifics.
 
+
 #### Maximum Data Type Width Is Configurable
+
 Not all targets support 64 bit wide types or even 32 bit wide types. Define the
 appropriate preprocessor symbols and Unity will omit all operations from
 compilation that exceed the maximum width of your target. See Unity
 documentation for specifics.
 
+
 ## The Assertions in All Their Blessed Glory
+
 ### Basic Fail and Ignore
 
 ##### `TEST_FAIL()`
+
 This fella is most often used in special conditions where your test code is
 performing logic beyond a simple assertion. That is, in practice, `TEST_FAIL()`
 will always be found inside a conditional code block.
@@ -139,25 +163,33 @@ code then verifies as a final step.
 [CException](https://github.com/ThrowTheSwitch/CException) project).
 
 ##### `TEST_IGNORE()`
+
 Marks a test case (i.e. function meant to contain test assertions) as ignored.
 Usually this is employed as a breadcrumb to come back and implement a test case.
 An ignored test case has effects if other assertions are in the enclosing test
 case (see Unity documentation for more).
 
 ### Boolean
+
 ##### `TEST_ASSERT (condition)`
+
 ##### `TEST_ASSERT_TRUE (condition)`
+
 ##### `TEST_ASSERT_FALSE (condition)`
+
 ##### `TEST_ASSERT_UNLESS (condition)`
+
 A simple wording variation on `TEST_ASSERT_FALSE`.The semantics of
 `TEST_ASSERT_UNLESS` aid readability in certain test constructions or
 conditional statements.
 
 ##### `TEST_ASSERT_NULL (pointer)`
+
 ##### `TEST_ASSERT_NOT_NULL (pointer)`
 
 
 ### Signed and Unsigned Integers (of all sizes)
+
 Large integer sizes can be disabled for build targets that do not support them.
 For example, if your target only supports up to 16 bit types, by defining the
 appropriate symbols Unity can be configured to omit 32 and 64 bit operations
@@ -166,86 +198,140 @@ Advanced Asserting later in this document for advice on dealing with other word
 sizes.
 
 ##### `TEST_ASSERT_EQUAL_INT (expected, actual)`
+
 ##### `TEST_ASSERT_EQUAL_INT8 (expected, actual)`
+
 ##### `TEST_ASSERT_EQUAL_INT16 (expected, actual)`
+
 ##### `TEST_ASSERT_EQUAL_INT32 (expected, actual)`
+
 ##### `TEST_ASSERT_EQUAL_INT64 (expected, actual)`
+
 ##### `TEST_ASSERT_EQUAL (expected, actual)`
+
 ##### `TEST_ASSERT_NOT_EQUAL (expected, actual)`
+
 ##### `TEST_ASSERT_EQUAL_UINT (expected, actual)`
+
 ##### `TEST_ASSERT_EQUAL_UINT8 (expected, actual)`
+
 ##### `TEST_ASSERT_EQUAL_UINT16 (expected, actual)`
+
 ##### `TEST_ASSERT_EQUAL_UINT32 (expected, actual)`
+
 ##### `TEST_ASSERT_EQUAL_UINT64 (expected, actual)`
 
+
 ### Unsigned Integers (of all sizes) in Hexadecimal
+
 All `_HEX` assertions are identical in function to unsigned integer assertions
 but produce failure messages with the `expected` and `actual` values formatted
 in hexadecimal. Unity output is big endian.
 
 ##### `TEST_ASSERT_EQUAL_HEX (expected, actual)`
+
 ##### `TEST_ASSERT_EQUAL_HEX8 (expected, actual)`
+
 ##### `TEST_ASSERT_EQUAL_HEX16 (expected, actual)`
+
 ##### `TEST_ASSERT_EQUAL_HEX32 (expected, actual)`
+
 ##### `TEST_ASSERT_EQUAL_HEX64 (expected, actual)`
 
+
 ### Masked and Bit-level Assertions
+
 Masked and bit-level assertions produce output formatted in hexadecimal. Unity
 output is big endian.
 
+
 ##### `TEST_ASSERT_BITS (mask, expected, actual)`
+
 Only compares the masked (i.e. high) bits of `expected` and `actual` parameters.
 
+
 ##### `TEST_ASSERT_BITS_HIGH (mask, actual)`
+
 Asserts the masked bits of the `actual` parameter are high.
 
+
 ##### `TEST_ASSERT_BITS_LOW (mask, actual)`
+
 Asserts the masked bits of the `actual` parameter are low.
 
+
 ##### `TEST_ASSERT_BIT_HIGH (bit, actual)`
+
 Asserts the specified bit of the `actual` parameter is high.
 
+
 ##### `TEST_ASSERT_BIT_LOW (bit, actual)`
+
 Asserts the specified bit of the `actual` parameter is low.
 
+
 ### Integer Ranges (of all sizes)
+
 These assertions verify that the `expected` parameter is within +/- `delta`
 (inclusive) of the `actual` parameter. For example, if the expected value is 10
 and the delta is 3 then the assertion will fail for any value outside the range
 of 7 - 13.
 
 ##### `TEST_ASSERT_INT_WITHIN (delta, expected, actual)`
+
 ##### `TEST_ASSERT_INT8_WITHIN (delta, expected, actual)`
+
 ##### `TEST_ASSERT_INT16_WITHIN (delta, expected, actual)`
+
 ##### `TEST_ASSERT_INT32_WITHIN (delta, expected, actual)`
+
 ##### `TEST_ASSERT_INT64_WITHIN (delta, expected, actual)`
+
 ##### `TEST_ASSERT_UINT_WITHIN (delta, expected, actual)`
+
 ##### `TEST_ASSERT_UINT8_WITHIN (delta, expected, actual)`
+
 ##### `TEST_ASSERT_UINT16_WITHIN (delta, expected, actual)`
+
 ##### `TEST_ASSERT_UINT32_WITHIN (delta, expected, actual)`
+
 ##### `TEST_ASSERT_UINT64_WITHIN (delta, expected, actual)`
+
 ##### `TEST_ASSERT_HEX_WITHIN (delta, expected, actual)`
+
 ##### `TEST_ASSERT_HEX8_WITHIN (delta, expected, actual)`
+
 ##### `TEST_ASSERT_HEX16_WITHIN (delta, expected, actual)`
+
 ##### `TEST_ASSERT_HEX32_WITHIN (delta, expected, actual)`
+
 ##### `TEST_ASSERT_HEX64_WITHIN (delta, expected, actual)`
 
+
 ### Structs and Strings
+
 ##### `TEST_ASSERT_EQUAL_PTR (expected, actual)`
+
 Asserts that the pointers point to the same memory location.
 
+
 ##### `TEST_ASSERT_EQUAL_STRING (expected, actual)`
-Asserts that the null terminated (`‘\0'`)strings are identical. If strings are 
+
+Asserts that the null terminated (`'\0'`)strings are identical. If strings are
 of different lengths or any portion of the strings before their terminators
 differ, the assertion fails. Two NULL strings (i.e. zero length) are considered
 equivalent.
 
+
 ##### `TEST_ASSERT_EQUAL_MEMORY (expected, actual, len)`
+
 Asserts that the contents of the memory specified by the `expected` and `actual`
 pointers is identical. The size of the memory blocks in bytes is specified by
 the `len` parameter.
 
+
 ### Arrays
+
 `expected` and `actual` parameters are both arrays. `num_elements` specifies the
 number of elements in the arrays to compare.
 
@@ -259,137 +345,205 @@ Assertions fail upon the first element in the compared arrays found not to
 match. Failure messages specify the array index of the failed comparison.
 
 ##### `TEST_ASSERT_EQUAL_INT_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_INT8_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_INT16_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_INT32_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_INT64_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_UINT_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_UINT8_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_UINT16_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_UINT32_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_UINT64_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_HEX_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_HEX8_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_HEX16_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_HEX32_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_HEX64_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_PTR_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_STRING_ARRAY (expected, actual, num_elements)`
+
 ##### `TEST_ASSERT_EQUAL_MEMORY_ARRAY (expected, actual, len, num_elements)`
+
 `len` is the memory in bytes to be compared at each array element.
 
+
 ### Floating Point (If enabled)
+
 ##### `TEST_ASSERT_FLOAT_WITHIN (delta, expected, actual)`
+
 Asserts that the `actual` value is within +/- `delta` of the `expected` value.
 The nature of floating point representation is such that exact evaluations of
 equality are not guaranteed.
 
+
 ##### `TEST_ASSERT_EQUAL_FLOAT (expected, actual)`
+
 Asserts that the ?actual?value is "close enough to be considered equal" to the
 `expected` value. If you are curious about the details, refer to the Advanced
 Asserting section for more details on this. Omitting a user-specified delta in a
 floating point assertion is both a shorthand convenience and a requirement of
 code generation conventions for CMock.
 
+
 ##### `TEST_ASSERT_EQUAL_FLOAT_ARRAY (expected, actual, num_elements)`
+
 See Array assertion section for details. Note that individual array element
 float comparisons are executed using T?EST_ASSERT_EQUAL_FLOAT?.That is, user
 specified delta comparison values requires a custom-implemented floating point
 array assertion.
 
+
 ##### `TEST_ASSERT_FLOAT_IS_INF (actual)`
+
 Asserts that `actual` parameter is equivalent to positive infinity floating
 point representation.
 
+
 ##### `TEST_ASSERT_FLOAT_IS_NEG_INF (actual)`
+
 Asserts that `actual` parameter is equivalent to negative infinity floating
 point representation.
 
+
 ##### `TEST_ASSERT_FLOAT_IS_NAN (actual)`
+
 Asserts that `actual` parameter is a Not A Number floating point representation.
 
+
 ##### `TEST_ASSERT_FLOAT_IS_DETERMINATE (actual)`
+
 Asserts that ?actual?parameter is a floating point representation usable for
 mathematical operations. That is, the `actual` parameter is neither positive
 infinity nor negative infinity nor Not A Number floating point representations.
 
+
 ##### `TEST_ASSERT_FLOAT_IS_NOT_INF (actual)`
+
 Asserts that `actual` parameter is a value other than positive infinity floating
 point representation.
 
+
 ##### `TEST_ASSERT_FLOAT_IS_NOT_NEG_INF (actual)`
+
 Asserts that `actual` parameter is a value other than negative infinity floating
 point representation.
 
+
 ##### `TEST_ASSERT_FLOAT_IS_NOT_NAN (actual)`
+
 Asserts that `actual` parameter is a value other than Not A Number floating
 point representation.
 
+
 ##### `TEST_ASSERT_FLOAT_IS_NOT_DETERMINATE (actual)`
+
 Asserts that `actual` parameter is not usable for mathematical operations. That
 is, the `actual` parameter is either positive infinity or negative infinity or
 Not A Number floating point representations.
 
+
 ### Double (If enabled)
+
 ##### `TEST_ASSERT_DOUBLE_WITHIN (delta, expected, actual)`
+
 Asserts that the `actual` value is within +/- `delta` of the `expected` value.
 The nature of floating point representation is such that exact evaluations of
 equality are not guaranteed.
 
+
 ##### `TEST_ASSERT_EQUAL_DOUBLE (expected, actual)`
+
 Asserts that the `actual` value is "close enough to be considered equal" to the
 `expected` value. If you are curious about the details, refer to the Advanced
 Asserting section for more details. Omitting a user-specified delta in a
 floating point assertion is both a shorthand convenience and a requirement of
 code generation conventions for CMock.
 
+
 ##### `TEST_ASSERT_EQUAL_DOUBLE_ARRAY (expected, actual, num_elements)`
+
 See Array assertion section for details. Note that individual array element
 double comparisons are executed using `TEST_ASSERT_EQUAL_DOUBLE`.That is, user
-specified delta comparison values requires a custom­implemented double array 
+specified delta comparison values requires a custom implemented double array
 assertion.
 
+
 ##### `TEST_ASSERT_DOUBLE_IS_INF (actual)`
+
 Asserts that `actual` parameter is equivalent to positive infinity floating
 point representation.
 
+
 ##### `TEST_ASSERT_DOUBLE_IS_NEG_INF (actual)`
+
 Asserts that `actual` parameter is equivalent to negative infinity floating point
 representation.
 
+
 ##### `TEST_ASSERT_DOUBLE_IS_NAN (actual)`
+
 Asserts that `actual` parameter is a Not A Number floating point representation.
 
+
 ##### `TEST_ASSERT_DOUBLE_IS_DETERMINATE (actual)`
+
 Asserts that `actual` parameter is a floating point representation usable for
 mathematical operations. That is, the ?actual?parameter is neither positive
 infinity nor negative infinity nor Not A Number floating point representations.
 
+
 ##### `TEST_ASSERT_DOUBLE_IS_NOT_INF (actual)`
+
 Asserts that `actual` parameter is a value other than positive infinity floating
 point representation.
 
+
 ##### `TEST_ASSERT_DOUBLE_IS_NOT_NEG_INF (actual)`
+
 Asserts that `actual` parameter is a value other than negative infinity floating
 point representation.
 
+
 ##### `TEST_ASSERT_DOUBLE_IS_NOT_NAN (actual)`
+
 Asserts that `actual` parameter is a value other than Not A Number floating
 point representation.
 
+
 ##### `TEST_ASSERT_DOUBLE_IS_NOT_DETERMINATE (actual)`
+
 Asserts that `actual` parameter is not usable for mathematical operations. That
 is, the `actual` parameter is either positive infinity or negative infinity or
 Not A Number floating point representations.
 
+
 ## Advanced Asserting: Details On Tricky Assertions
+
 This section helps you understand how to deal with some of the trickier
 assertion situations you may run into. It will give you a glimpse into some of
 the under-the-hood details of Unity's assertion mechanisms. If you're one of
 those people who likes to know what is going on in the background, read on. If
 not, feel free to ignore the rest of this document until you need it.
 
+
 ### How do the EQUAL assertions work for FLOAT and DOUBLE?
+
 As you may know, directly checking for equality between a pair of floats or a
 pair of doubles is sloppy at best and an outright no-no at worst. Floating point
 values can often be represented in multiple ways, particularly after a series of
@@ -428,7 +582,9 @@ assertions less strict, you can change these multipliers to whatever you like by
 defining UNITY_FLOAT_PRECISION and UNITY_DOUBLE_PRECISION. See Unity
 documentation for more.
 
+
 ### How do we deal with targets with non-standard int sizes?
+
 It's "fun" that C is a standard where something as fundamental as an integer
 varies by target. According to the C standard, an `int` is to be the target's
 natural register size, and it should be at least 16-bits and a multiple of a

docs/UnityConfigurationGuide.md

 # Unity Configuration Guide
 
 ## C Standards, Compilers and Microcontrollers
+
 The embedded software world contains its challenges. Compilers support different
 revisions of the C Standard. They ignore requirements in places, sometimes to
 make the language more usable in some special regard. Sometimes it's to simplify
@@ -21,7 +22,9 @@ challenging to build. From a more positive perspective, it is also proof that a
 great deal of complexity can be centralized primarily to one place in order to
 provide a more consistent and simple experience elsewhere.
 
+
 ### Using These Options
+
 It doesn't matter if you're using a target-specific compiler and a simulator or
 a native compiler. In either case, you've got a couple choices for configuring
 these options:
@@ -36,9 +39,11 @@ toolchain's search paths). In this file, you will list definitions and macros
 specific to your target. All you must do is define `UNITY_INCLUDE_CONFIG_H` and
 Unity will rely on `unity_config.h` for any further definitions it may need.
 
+
 ## The Options
 
 ### Integer Types
+
 If you've been a C developer for long, you probably already know that C's
 concept of an integer varies from target to target. The C Standard has rules
 about the `int` matching the register size of the target microprocessor. It has
@@ -49,7 +54,9 @@ certainly not every compiler you are likely to encounter. Therefore, Unity has a
 number of features for helping to adjust itself to match your required integer
 sizes. It starts off by trying to do it automatically.
 
+
 ##### `UNITY_EXCLUDE_STDINT_H`
+
 The first thing that Unity does to guess your types is check `stdint.h`.
 This file includes defines like `UINT_MAX` that Unity can make use of to
 learn a lot about your system. It's possible you don't want it to do this
@@ -61,7 +68,9 @@ be left with a compiler error.
 _Example:_
         #define UNITY_EXCLUDE_STDINT_H
 
+
 ##### `UNITY_EXCLUDE_LIMITS_H`
+
 The second attempt to guess your types is to check `limits.h`. Some compilers
 that don't support `stdint.h` could include `limits.h` instead. If you don't
 want Unity to check this file either, define this to make it skip the inclusion.
@@ -69,7 +78,9 @@ want Unity to check this file either, define this to make it skip the inclusion.
 _Example:_
         #define UNITY_EXCLUDE_LIMITS_H
 
+
 ##### `UNITY_EXCLUDE_SIZEOF`
+
 The third and final attempt to guess your types is to use the `sizeof()`
 operator. Even if the first two options don't work, this one covers most cases.
 There _is_ a rare compiler or two out there that doesn't support sizeof() in the
@@ -84,14 +95,18 @@ do the configuration yourself. Don't worry. Even this isn't too bad... there are
 just a handful of defines that you are going to specify if you don't like the
 defaults.
 
+
 ##### `UNITY_INT_WIDTH`
+
 Define this to be the number of bits an `int` takes up on your system. The
 default, if not autodetected, is 32 bits.
 
 _Example:_
         #define UNITY_INT_WIDTH 16
 
+
 ##### `UNITY_LONG_WIDTH`
+
 Define this to be the number of bits a `long` takes up on your system. The
 default, if not autodetected, is 32 bits. This is used to figure out what kind
 of 64-bit support your system can handle. Does it need to specify a `long` or a
@@ -101,7 +116,9 @@ ignored.
 _Example:_
         #define UNITY_LONG_WIDTH 16
 
+
 ##### `UNITY_POINTER_WIDTH`
+
 Define this to be the number of bits a pointer takes up on your system. The
 default, if not autodetected, is 32-bits. If you're getting ugly compiler
 warnings about casting from pointers, this is the one to look at.
@@ -109,7 +126,9 @@ warnings about casting from pointers, this is the one to look at.
 _Example:_
         #define UNITY_POINTER_WIDTH 64
 
+
 ##### `UNITY_INCLUDE_64`
+
 Unity will automatically include 64-bit support if it auto-detects it, or if
 your `int`, `long`, or pointer widths are greater than 32-bits. Define this to
 enable 64-bit support if none of the other options already did it for you. There
@@ -119,7 +138,9 @@ targets, so don't define it if you don't need it.
 _Example:_
         #define UNITY_INCLUDE_64
 
+
 ### Floating Point Types
+
 In the embedded world, it's not uncommon for targets to have no support for
 floating point operations at all or to have support that is limited to only
 single precision. We are able to guess integer sizes on the fly because integers
@@ -127,10 +148,15 @@ are always available in at least one size. Floating point, on the other hand, is
 sometimes not available at all. Trying to include `float.h` on these platforms
 would result in an error. This leaves manual configuration as the only option.
 
+
 ##### `UNITY_INCLUDE_FLOAT`
+
 ##### `UNITY_EXCLUDE_FLOAT`
+
 ##### `UNITY_INCLUDE_DOUBLE`
+
 ##### `UNITY_EXCLUDE_DOUBLE`
+
 By default, Unity guesses that you will want single precision floating point
 support, but not double precision. It's easy to change either of these using the
 include and exclude options here. You may include neither, either, or both, as
@@ -143,8 +169,11 @@ _Example:_
         #define UNITY_EXCLUDE_FLOAT
         #define UNITY_INCLUDE_DOUBLE
 
+
 ##### `UNITY_FLOAT_VERBOSE`
+
 ##### `UNITY_DOUBLE_VERBOSE`
+
 Unity aims for as small of a footprint as possible and avoids most standard
 library calls (some embedded platforms don't have a standard library!). Because
 of this, its routines for printing integer values are minimalist and hand-coded.
@@ -160,7 +189,9 @@ use of `sprintf` so might not be desirable in all cases.
 _Example:_
         #define UNITY_DOUBLE_VERBOSE
 
+
 ##### `UNITY_FLOAT_TYPE`
+
 If enabled, Unity assumes you want your `FLOAT` asserts to compare standard C
 floats. If your compiler supports a specialty floating point type, you can
 always override this behavior by using this definition.
@@ -168,7 +199,9 @@ always override this behavior by using this definition.
 _Example:_
         #define UNITY_FLOAT_TYPE float16_t
 
+
 ##### `UNITY_DOUBLE_TYPE`
+
 If enabled, Unity assumes you want your `DOUBLE` asserts to compare standard C
 doubles. If you would like to change this, you can specify something else by
 using this option. For example, defining `UNITY_DOUBLE_TYPE` to `long double`
@@ -178,8 +211,11 @@ the standard `double`.
 _Example:_
         #define UNITY_DOUBLE_TYPE long double
 
+
 ##### `UNITY_FLOAT_PRECISION`
+
 ##### `UNITY_DOUBLE_PRECISION`
+
 If you look up `UNITY_ASSERT_EQUAL_FLOAT` and `UNITY_ASSERT_EQUAL_DOUBLE` as
 documented in the big daddy Unity Assertion Guide, you will learn that they are
 not really asserting that two values are equal but rather that two values are
@@ -194,7 +230,9 @@ Guide.
 _Example:_
         #define UNITY_FLOAT_PRECISION 0.001f
 
+
 ### Toolset Customization
+
 In addition to the options listed above, there are a number of other options
 which will come in handy to customize Unity's behavior for your specific
 toolchain. It is possible that you may not need to touch any of these... but
@@ -202,10 +240,15 @@ certain platforms, particularly those running in simulators, may need to jump
 through extra hoops to operate properly. These macros will help in those
 situations.
 
+
 ##### `UNITY_OUTPUT_CHAR(a)`
+
 ##### `UNITY_OUTPUT_FLUSH()`
+
 ##### `UNITY_OUTPUT_START()`
+
 ##### `UNITY_OUTPUT_COMPLETE()`
+
 By default, Unity prints its results to `stdout` as it runs. This works
 perfectly fine in most situations where you are using a native compiler for
 testing. It works on some simulators as well so long as they have `stdout`
@@ -233,7 +276,9 @@ specify a custom flush function instead with `UNITY_OUTPUT_FLUSH` directly, it
 will declare an instance of your function by default. If you want to disable
 this behavior, add `UNITY_OMIT_OUTPUT_FLUSH_HEADER_DECLARATION`.
 
+
 ##### `UNITY_SUPPORT_WEAK`
+
 For some targets, Unity can make the otherwise required `setUp()` and
 `tearDown()` functions optional. This is a nice convenience for test writers
 since `setUp` and `tearDown` don't often actually _do_ anything. If you're using
@@ -252,7 +297,9 @@ _Example:_
         #define UNITY_SUPPORT_WEAK weak
         #define UNITY_SUPPORT_WEAK __attribute__((weak))
 
+
 ##### `UNITY_PTR_ATTRIBUTE`
+
 Some compilers require a custom attribute to be assigned to pointers, like
 `near` or `far`. In these cases, you can give Unity a safe default for these by
 defining this option with the attribute you would like.
@@ -261,7 +308,9 @@ _Example:_
         #define UNITY_PTR_ATTRIBUTE __attribute__((far))
         #define UNITY_PTR_ATTRIBUTE near
 
+
 ## Getting Into The Guts
+
 There will be cases where the options above aren't quite going to get everything
 perfect. They are likely sufficient for any situation where you are compiling
 and executing your tests with a native toolchain (e.g. clang on Mac). These
@@ -272,7 +321,9 @@ require special help. This special help will usually reside in one of two
 places: the `main()` function or the `RUN_TEST` macro. Let's look at how these
 work.
 
+
 ##### `main()`
+
 Each test module is compiled and run on its own, separate from the other test
 files in your project. Each test file, therefore, has a `main` function. This
 `main` function will need to contain whatever code is necessary to initialize
@@ -301,7 +352,9 @@ after all the test cases have completed. This allows you to do any needed
 system-wide setup or teardown that might be required for your special
 circumstances.
 
+
 ##### `RUN_TEST`
+
 The `RUN_TEST` macro is called with each test case function. Its job is to
 perform whatever setup and teardown is necessary for executing a single test
 case function. This includes catching failures, calling the test module's
@@ -334,7 +387,9 @@ each result set. Again, you could do this by adding lines to this macro. Updates
 to this macro are for the occasions when you need an action before or after
 every single test case throughout your entire suite of tests.
 
+
 ## Happy Porting
+
 The defines and macros in this guide should help you port Unity to just about
 any C target we can imagine. If you run into a snag or two, don't be afraid of
 asking for help on the forums. We love a good challenge!
\ No newline at end of file

docs/UnityGettingStartedGuide.md

 # Unity - Getting Started
 
 ## Welcome
+
 Congratulations. You're now the proud owner of your very own pile of bits! What
 are you going to do with all these ones and zeros? This document should be able
 to help you decide just that.
@@ -16,60 +17,74 @@ rules. Unity has been used with many compilers, including GCC, IAR, Clang,
 Green Hills, Microchip, and MS Visual Studio. It's not much work to get it to
 work with a new target.
 
+
 ### Overview of the Documents
 
 #### Unity Assertions reference
+
 This document will guide you through all the assertion options provided by
 Unity. This is going to be your unit testing bread and butter. You'll spend more
 time with assertions than any other part of Unity.
 
+
 #### Unity Assertions Cheat Sheet
+
 This document contains an abridged summary of the assertions described in the
 previous document. It's perfect for printing and referencing while you
 familiarize yourself with Unity's options.
 
+
 #### Unity Configuration Guide
+
 This document is the one to reference when you are going to use Unity with a new
 target or compiler. It'll guide you through the configuration options and will
 help you customize your testing experience to meet your needs.
 
+
 #### Unity Helper Scripts
+
 This document describes the helper scripts that are available for simplifying
 your testing workflow. It describes the collection of optional Ruby scripts
 included in the auto directory of your Unity installation. Neither Ruby nor
 these scripts are necessary for using Unity. They are provided as a convenience
 for those who wish to use them.
 
+
 #### Unity License
+
 What's an open source project without a license file? This brief document
 describes the terms you're agreeing to when you use this software. Basically, we
 want it to be useful to you in whatever context you want to use it, but please
 don't blame us if you run into problems.
 
+
 ### Overview of the Folders
+
 If you have obtained Unity through Github or something similar, you might be
 surprised by just how much stuff you suddenly have staring you in the face.
 Don't worry, Unity itself is very small. The rest of it is just there to make
 your life easier. You can ignore it or use it at your convenience. Here's an
 overview of everything in the project.
 
-- `src` — This is the code you care about! This folder contains a C file and two 
+- `src` - This is the code you care about! This folder contains a C file and two
 header files. These three files _are_ Unity.
-- `docs` — You're reading this document, so it's possible you have found your way 
+- `docs` - You're reading this document, so it's possible you have found your way
 into this folder already. This is where all the handy documentation can be
 found.
-- `examples` — This contains a few examples of using Unity.
-- `extras` — These are optional add ons to Unity that are not part of the core 
+- `examples` - This contains a few examples of using Unity.
+- `extras` - These are optional add ons to Unity that are not part of the core
 project. If you've reached us through James Grenning's book, you're going to
 want to look here.
-- `test` — This is how Unity and its scripts are all tested. If you're just using 
+- `test` - This is how Unity and its scripts are all tested. If you're just using
 Unity, you'll likely never need to go in here. If you are the lucky team member
 who gets to port Unity to a new toolchain, this is a good place to verify
 everything is configured properly.
-- `auto` — Here you will find helpful Ruby scripts for simplifying your test 
+- `auto` - Here you will find helpful Ruby scripts for simplifying your test
 workflow. They are purely optional and are not required to make use of Unity.
 
+
 ## How to Create A Test File
+
 Test files are C files. Most often you will create a single test file for each C
 module that you want to test. The test file should include unity.h and the
 header for your C module to be tested.
@@ -126,10 +141,10 @@ void test_function_should_doAlsoDoBlah(void) {
 }
 
 int main(void) {
-    UNITY_BEGIN(); 
-    RUN_TEST(test_function_should_doBlahAndBlah); 
-    RUN_TEST(test_function_should_doAlsoDoBlah); 
-    return UNITY_END(); 
+    UNITY_BEGIN();
+    RUN_TEST(test_function_should_doBlahAndBlah);
+    RUN_TEST(test_function_should_doAlsoDoBlah);
+    return UNITY_END();
 }
 ```
 
@@ -137,7 +152,9 @@ It's possible that you will require more customization than this, eventually.
 For that sort of thing, you're going to want to look at the configuration guide.
 This should be enough to get you going, though.
 
+
 ## How to Build and Run A Test File
+
 This is the single biggest challenge to picking up a new unit testing framework,
 at least in a language like C or C++. These languages are REALLY good at getting
 you "close to the metal" (why is the phrase metal? Wouldn't it be more accurate

docs/UnityHelperScriptsGuide.md

 # Unity Helper Scripts
+
 ## With a Little Help From Our Friends
+
 Sometimes what it takes to be a really efficient C programmer is a little non-C.
 The Unity project includes a couple Ruby scripts for making your life just a tad
 easier. They are completely optional. If you choose to use them, you'll need a
 copy of Ruby, of course. Just install whatever the latest version is, and it is
 likely to work. You can find Ruby at [ruby-lang.org](https://ruby-labg.org/).
 
+
 ### `generate_test_runner.rb`
+
 Are you tired of creating your own `main` function in your test file? Do you
 keep forgetting to add a `RUN_TEST` call when you add a new test case to your
 suite? Do you want to use CMock or other fancy add-ons but don't want to figure
@@ -111,30 +115,41 @@ end
 ```
 
 #### Options accepted by generate_test_runner.rb:
+
 The following options are available when executing `generate_test_runner`. You
 may pass these as a Ruby hash directly or specify them in a YAML file, both of
 which are described above. In the `examples` directory, Example 3's Rakefile
 demonstrates using a Ruby hash.
 
+
 ##### `:includes`
+
 This option specifies an array of file names to be ?#include?'d at the top of
 your runner C file. You might use it to reference custom types or anything else
 universally needed in your generated runners.
 
+
 ##### `:suite_setup`
+
 Define this option with C code to be executed _before any_ test cases are run.
 
+
 ##### `:suite_teardown`
+
 Define this option with C code to be executed ?after all?test cases have
 finished.
 
+
 ##### `:enforce_strict_ordering`
+
 This option should be defined if you have the strict order feature enabled in
 CMock (see CMock documentation). This generates extra variables required for
 everything to run smoothly. If you provide the same YAML to the generator as
 used in CMock's configuration, you've already configured the generator properly.
 
+
 ##### `:plugins`
+
 This option specifies an array of plugins to be used (of course, the array can
 contain only a single plugin). This is your opportunity to enable support for
 CException support, which will add a check for unhandled exceptions in each
@@ -155,7 +170,9 @@ If you are using CMock, it is very likely that you are already passing an array
 of plugins to CMock. You can just use the same array here. This script will just
 ignore the plugins that don't require additional support.
 
+
 ### `unity_test_summary.rb`
+
 A Unity test file contains one or more test case functions. Each test case can
 pass, fail, or be ignored. Each test file is run individually producing results
 for its collection of test cases. A given project will almost certainly be