ceedling 0.31.0 → 0.31.1

data/vendor/cmock/vendor/c_exception/README.md

@@ -1,5 +1,7 @@
-CException ![CI](https://github.com/ThrowTheSwitch/CException/workflows/CI/badge.svg)
-==========
+CException - Lightweight exception library for C
+================================================
+
+[![CException Build Status](https://api.travis-ci.org/ThrowTheSwitch/CException.png?branch=master)](https://travis-ci.org/ThrowTheSwitch/CException)
 
 _This Documentation Is Released Under a Creative Commons 3.0 Attribution Share-Alike License_
 
@@ -125,7 +127,7 @@ location was updated and not just a register unless the variable is marked volat
 ### Memory Management
 
 Memory which is `malloc`'d within a `Try` block is not automatically released when an error is thrown. This 
-will sometimes be desirable, and other times may not. It will be the responsibility of the code you put in 
+will sometimes be desirable, and othertimes may not. It will be the responsibility of the code you put in 
 the `Catch` block to perform this kind of cleanup.
 
 There's just no easy way to track `malloc`'d memory, etc., without replacing or wrapping `malloc` 
@@ -239,7 +241,7 @@ License
 =======
 
 *This software is licensed under the MIT License:
-Copyright (c) 2007-2021 Mark VanderVoord*
+Copyright (c) 2007-2019 Mark VanderVoord*
 
 *Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
 The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.*

data/vendor/cmock/vendor/c_exception/docs/CException.md

@@ -145,7 +145,7 @@ to successfully utilize this library:
 
 3. Memory which is `malloc`'d or `new`'d is not automatically released
    when an error is thrown.  This will sometimes be desirable, and
-   other times may not.  It will be the responsibility of the `Catch`
+   othertimes may not.  It will be the responsibility of the `Catch`
    block to perform this kind of cleanup.
 
    *Why?*
@@ -311,7 +311,7 @@ LICENSE
 
 This software is licensed under the MIT License
 
-Copyright (c) 2007-2021 Mark VanderVoord
+Copyright (c) 2007-2020 Mark VanderVoord
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal

data/vendor/cmock/vendor/c_exception/lib/CException.h

@@ -11,7 +11,7 @@ extern "C"
 
 #define CEXCEPTION_VERSION_MAJOR    1
 #define CEXCEPTION_VERSION_MINOR    3
-#define CEXCEPTION_VERSION_BUILD    3
+#define CEXCEPTION_VERSION_BUILD    2
 #define CEXCEPTION_VERSION          ((CEXCEPTION_VERSION_MAJOR << 16) | (CEXCEPTION_VERSION_MINOR << 8) | CEXCEPTION_VERSION_BUILD)
 
 //To Use CException, you have a number of options:

data/vendor/cmock/vendor/c_exception/lib/meson.build

@@ -7,5 +7,5 @@
 cexception_dir = include_directories('.')
 
 cexception_lib = static_library(meson.project_name(), 
-    files('CException.c'),
-    include_directories : cexception_dir)
+    sources: ['CException.c'],
+    include_directories: cexception_dir)

data/vendor/cmock/vendor/c_exception/meson.build

@@ -4,11 +4,45 @@
 #
 # license: MIT
 #
-project('cexception', 'c',
+project('CException', 'c',
     license: 'MIT',
     meson_version: '>=0.53.0',
-    default_options: ['werror=true', 'c_std=c11']
+    default_options: ['layout=flat', 'warning_level=3', 'werror=true', 'c_std=c11']
 )
+lang = 'c'
+cc = meson.get_compiler(lang)
 
+#
+# Meson: Add compiler flags
+if cc.get_id() == 'clang'
+    add_project_arguments(cc.get_supported_arguments(
+            [
+                '-Wexit-time-destructors',
+                '-Wglobal-constructors',
+                '-Wmissing-prototypes',
+                '-Wmissing-noreturn',
+                '-Wno-missing-braces',
+                '-Wold-style-cast', '-Wpointer-arith', '-Wweak-vtables',
+                '-Wcast-align', '-Wconversion', '-Wcast-qual', '-Wshadow'
+            ]
+        ), language: lang)
+endif
+
+if cc.get_argument_syntax() == 'gcc'
+    add_project_arguments(cc.get_supported_arguments(
+            [
+                '-Wformat', '-Waddress', '-Winit-self', '-Wno-multichar',
+                '-Wpointer-arith'       , '-Wwrite-strings'              ,
+                '-Wno-parentheses'      , '-Wno-type-limits'             ,
+                '-Wformat-security'     , '-Wunreachable-code'           ,
+                '-Waggregate-return'    , '-Wformat-nonliteral'          ,
+                '-Wmissing-declarations', '-Wmissing-include-dirs'       ,
+                '-Wno-unused-parameter'
+            ]
+        ), language: lang)
+endif
+
+#
+# Sub directory to project source code
 subdir('lib')
 cexception_dep = declare_dependency(link_with: cexception_lib, include_directories: cexception_dir)

data/vendor/cmock/vendor/unity/README.md

@@ -1,29 +1,26 @@
-Unity Test ![CI](https://github.com/ThrowTheSwitch/Unity/workflows/CI/badge.svg)
-==========
+# Unity Test ![CI][]
+
 __Copyright (c) 2007 - 2021 Unity Project by Mike Karlesky, Mark VanderVoord, and Greg Williams__
 
-Welcome to the Unity Test Project, one of the main projects of ThrowTheSwitch.org. Unity Test is a 
-unit testing framework built for C, with a focus on working with embedded toolchains. 
+Welcome to the Unity Test Project, one of the main projects of ThrowTheSwitch.org.
+Unity Test is a unit testing framework built for C, with a focus on working with embedded toolchains.
+
+This project is made to test code targetting microcontrollers big and small.
+The core project is a single C file and a pair of headers, allowing it to the added to your existing build setup without too much headache.
+You may use any compiler you wish, and may use most existing build systems including Make, CMake, etc.
+If you'd like to leave the hard work to us, you might be interested in Ceedling, a build tool also by ThrowTheSwitch.org.
 
-This project is made to test code targetting microcontrollers big and small. The core project is a 
-single C file and a pair of headers, allowing it to the added to your existing build setup without 
-too much headache. You may use any compiler you wish, and may use most existing build systems
-including make, cmake, etc. If you'd like to leave the hard work to us, you might be interested
-in Ceedling, a build tool also by ThrowTheSwitch.org. 
+If you're new to Unity, we encourage you to tour the [getting started guide][].
 
-If you're new to Unity, we encourage you to tour the [getting started guide](docs/UnityGettingStartedGuide.md)
+## Getting Started
 
-Getting Started
-===============
-The [docs](docs/) folder contains a [getting started guide](docs/UnityGettingStartedGuide.md)
-and much more tips about using Unity. 
+The [docs][] folder contains a [getting started guide][] and much more tips about using Unity.
 
-Unity Assertion Summary
-=======================
-For the full list, see [UnityAssertionsReference.md](docs/UnityAssertionsReference.md).
+## Unity Assertion Summary
 
-Basic Validity Tests
---------------------
+For the full list, see [UnityAssertionsReference.md][].
+
+### Basic Validity Tests
 
     TEST_ASSERT_TRUE(condition)
 
@@ -44,10 +41,10 @@ Another way of calling `TEST_ASSERT_FALSE`
     TEST_FAIL()
     TEST_FAIL_MESSAGE(message)
 
-This test is automatically marked as a failure. The message is output stating why.
+This test is automatically marked as a failure.
+The message is output stating why.
 
-Numerical Assertions: Integers
-------------------------------
+### Numerical Assertions: Integers
 
     TEST_ASSERT_EQUAL_INT(expected, actual)
     TEST_ASSERT_EQUAL_INT8(expected, actual)
@@ -55,9 +52,9 @@ Numerical Assertions: Integers
     TEST_ASSERT_EQUAL_INT32(expected, actual)
     TEST_ASSERT_EQUAL_INT64(expected, actual)
 
-Compare two integers for equality and display errors as signed integers. A cast will be performed
-to your natural integer size so often this can just be used. When you need to specify the exact size,
-like when comparing arrays, you can use a specific version:
+Compare two integers for equality and display errors as signed integers.
+A cast will be performed to your natural integer size so often this can just be used.
+When you need to specify the exact size, like when comparing arrays, you can use a specific version:
 
     TEST_ASSERT_EQUAL_UINT(expected, actual)
     TEST_ASSERT_EQUAL_UINT8(expected, actual)
@@ -65,8 +62,8 @@ like when comparing arrays, you can use a specific version:
     TEST_ASSERT_EQUAL_UINT32(expected, actual)
     TEST_ASSERT_EQUAL_UINT64(expected, actual)
 
-Compare two integers for equality and display errors as unsigned integers. Like INT, there are
-variants for different sizes also.
+Compare two integers for equality and display errors as unsigned integers.
+Like INT, there are variants for different sizes also.
 
     TEST_ASSERT_EQUAL_HEX(expected, actual)
     TEST_ASSERT_EQUAL_HEX8(expected, actual)
@@ -74,9 +71,8 @@ variants for different sizes also.
     TEST_ASSERT_EQUAL_HEX32(expected, actual)
     TEST_ASSERT_EQUAL_HEX64(expected, actual)
 
-Compares two integers for equality and display errors as hexadecimal. Like the other integer comparisons,
-you can specify the size... here the size will also effect how many nibbles are shown (for example, `HEX16`
-will show 4 nibbles).
+Compares two integers for equality and display errors as hexadecimal.
+Like the other integer comparisons, you can specify the size... here the size will also effect how many nibbles are shown (for example, `HEX16` will show 4 nibbles).
 
     TEST_ASSERT_EQUAL(expected, actual)
 
@@ -84,63 +80,66 @@ Another way of calling TEST_ASSERT_EQUAL_INT
 
     TEST_ASSERT_INT_WITHIN(delta, expected, actual)
 
-Asserts that the actual value is within plus or minus delta of the expected value. This also comes in
-size specific variants.
-
+Asserts that the actual value is within plus or minus delta of the expected value.
+This also comes in size specific variants.
 
     TEST_ASSERT_GREATER_THAN(threshold, actual)
 
-Asserts that the actual value is greater than the threshold. This also comes in size specific variants.
-
+Asserts that the actual value is greater than the threshold.
+This also comes in size specific variants.
 
     TEST_ASSERT_LESS_THAN(threshold, actual)
 
-Asserts that the actual value is less than the threshold. This also comes in size specific variants.
-
+Asserts that the actual value is less than the threshold.
+This also comes in size specific variants.
 
-Arrays
-------
+### Arrays
 
     _ARRAY
 
-You can append `_ARRAY` to any of these macros to make an array comparison of that type.  Here you will
-need to care a bit more about the actual size of the value being checked.  You will also specify an
-additional argument which is the number of elements to compare.  For example:
+You can append `_ARRAY` to any of these macros to make an array comparison of that type.
+Here you will need to care a bit more about the actual size of the value being checked.
+You will also specify an additional argument which is the number of elements to compare.
+For example:
 
     TEST_ASSERT_EQUAL_HEX8_ARRAY(expected, actual, elements)
 
     _EACH_EQUAL
 
-Another array comparison option is to check that EVERY element of an array is equal to a single expected
-value. You do this by specifying the EACH_EQUAL macro. For example:
+Another array comparison option is to check that EVERY element of an array is equal to a single expected value.
+You do this by specifying the EACH_EQUAL macro.
+For example:
 
     TEST_ASSERT_EACH_EQUAL_INT32(expected, actual, elements)
 
-Numerical Assertions: Bitwise
------------------------------
+### Numerical Assertions: Bitwise
 
     TEST_ASSERT_BITS(mask, expected, actual)
 
-Use an integer mask to specify which bits should be compared between two other integers.  High bits in the mask are compared, low bits ignored.
+Use an integer mask to specify which bits should be compared between two other integers.
+High bits in the mask are compared, low bits ignored.
 
     TEST_ASSERT_BITS_HIGH(mask, actual)
 
-Use an integer mask to specify which bits should be inspected to determine if they are all set high.  High bits in the mask are compared, low bits ignored.
+Use an integer mask to specify which bits should be inspected to determine if they are all set high.
+High bits in the mask are compared, low bits ignored.
 
     TEST_ASSERT_BITS_LOW(mask, actual)
 
-Use an integer mask to specify which bits should be inspected to determine if they are all set low.  High bits in the mask are compared, low bits ignored.
+Use an integer mask to specify which bits should be inspected to determine if they are all set low.
+High bits in the mask are compared, low bits ignored.
 
     TEST_ASSERT_BIT_HIGH(bit, actual)
 
-Test a single bit and verify that it is high.  The bit is specified 0-31 for a 32-bit integer.
+Test a single bit and verify that it is high.
+The bit is specified 0-31 for a 32-bit integer.
 
     TEST_ASSERT_BIT_LOW(bit, actual)
 
-Test a single bit and verify that it is low.  The bit is specified 0-31 for a 32-bit integer.
+Test a single bit and verify that it is low.
+The bit is specified 0-31 for a 32-bit integer.
 
-Numerical Assertions: Floats
-----------------------------
+### Numerical Assertions: Floats
 
     TEST_ASSERT_FLOAT_WITHIN(delta, expected, actual)
 
@@ -151,29 +150,34 @@ Asserts that the actual value is within plus or minus delta of the expected valu
 
 Asserts that two floating point values are "equal" within a small % delta of the expected value.
 
-String Assertions
------------------
+### String Assertions
 
     TEST_ASSERT_EQUAL_STRING(expected, actual)
 
-Compare two null-terminate strings.  Fail if any character is different or if the lengths are different.
+Compare two null-terminate strings.
+Fail if any character is different or if the lengths are different.
 
     TEST_ASSERT_EQUAL_STRING_LEN(expected, actual, len)
 
-Compare two strings.  Fail if any character is different, stop comparing after len characters.
+Compare two strings.
+Fail if any character is different, stop comparing after len characters.
 
     TEST_ASSERT_EQUAL_STRING_MESSAGE(expected, actual, message)
 
-Compare two null-terminate strings.  Fail if any character is different or if the lengths are different. Output a custom message on failure.
+Compare two null-terminate strings.
+Fail if any character is different or if the lengths are different.
+Output a custom message on failure.
 
     TEST_ASSERT_EQUAL_STRING_LEN_MESSAGE(expected, actual, len, message)
 
-Compare two strings. Fail if any character is different, stop comparing after len characters. Output a custom message on failure.
+Compare two strings.
+Fail if any character is different, stop comparing after len characters.
+Output a custom message on failure.
 
-Pointer Assertions
-------------------
+### Pointer Assertions
 
-Most pointer operations can be performed by simply using the integer comparisons above. However, a couple of special cases are added for clarity.
+Most pointer operations can be performed by simply using the integer comparisons above.
+However, a couple of special cases are added for clarity.
 
     TEST_ASSERT_NULL(pointer)
 
@@ -183,18 +187,20 @@ Fails if the pointer is not equal to NULL
 
 Fails if the pointer is equal to NULL
 
-Memory Assertions
------------------
+### Memory Assertions
 
     TEST_ASSERT_EQUAL_MEMORY(expected, actual, len)
 
-Compare two blocks of memory.  This is a good generic assertion for types that can't be coerced into acting like
-standard types... but since it's a memory compare, you have to be careful that your data types are packed.
+Compare two blocks of memory.
+This is a good generic assertion for types that can't be coerced into acting like standard types... but since it's a memory compare, you have to be careful that your data types are packed.
 
-\_MESSAGE
----------
+### \_MESSAGE
 
-you can append \_MESSAGE to any of the macros to make them take an additional argument.  This argument
-is a string that will be printed at the end of the failure strings.  This is useful for specifying more
-information about the problem.
+You can append `\_MESSAGE` to any of the macros to make them take an additional argument.
+This argument is a string that will be printed at the end of the failure strings.
+This is useful for specifying more information about the problem.
 
+[CI]: https://github.com/ThrowTheSwitch/Unity/workflows/CI/badge.svg
+[getting started guide]: docs/UnityGettingStartedGuide.md
+[docs]: docs/
+[UnityAssertionsReference.md]: docs/UnityAssertionsReference.md

data/vendor/cmock/vendor/unity/auto/generate_test_runner.rb

@@ -143,7 +143,7 @@ class UnityTestRunnerGenerator
         arguments.scan(/\s*TEST_CASE\s*\((.*)\)\s*$/) { |a| args << a[0] }
 
         arguments.scan(/\s*TEST_RANGE\s*\((.*)\)\s*$/).flatten.each do |range_str|
-          args += range_str.scan(/\[(-?\d+.?\d*), *(-?\d+.?\d*), *(-?\d+.?\d*)\]/).map do |arg_values_str|
+          args += range_str.scan(/\[\s*(-?\d+.?\d*),\s*(-?\d+.?\d*),\s*(-?\d+.?\d*)\s*\]/).map do |arg_values_str|
             arg_values_str.map do |arg_value_str|
               arg_value_str.include?('.') ? arg_value_str.to_f : arg_value_str.to_i
             end

data/vendor/cmock/vendor/unity/docs/ThrowTheSwitchCodingStandard.md

@@ -1,136 +1,116 @@
 # 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
-followed. We're not perfect. Please be polite where you notice these discrepancies
-and we'll try to be polite when we notice yours.
+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 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 tried 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.
-
+Being consistent makes code easier to understand.
+We've tried 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
-made us more tolerant of compiler quirks. There are a LOT of quirky compilers
-out there. By quirky I mean "doesn't follow standards because they feel like
-they have a license to do as they wish."
-
-Our philosophy is "support every compiler we can". Most often, this means that
-we aim for writing C code that is standards compliant (often C89... that seems
-to be a sweet spot that is almost always compatible). But it also means these
-tools are tolerant of things that aren't common. Some that aren't even
-compliant. There are configuration options to override the size of standard
-types. There are configuration options to force Unity to not use certain
-standard library functions. A lot of Unity is configurable and we have worked
-hard to make it not TOO ugly in the process.
-
-Similarly, our tools that parse C do their best. They aren't full C parsers
-(yet) and, even if they were, they would still have to accept non-standard
-additions like gcc extensions or specifying `@0x1000` to force a variable to
-compile to a particular location. It's just what we do, because we like
-everything to Just Work™.
-
-Speaking of having things Just Work™, that's our second philosophy. By that, we
-mean that we do our best to have EVERY configuration option have a logical
-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.
+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 made us more tolerant of compiler quirks.
+There are a LOT of quirky compilers out there.
+By quirky I mean "doesn't follow standards because they feel like they have a license to do as they wish."
+
+Our philosophy is "support every compiler we can".
+Most often, this means that we aim for writing C code that is standards compliant (often C89... that seems to be a sweet spot that is almost always compatible).
+But it also means these tools are tolerant of things that aren't common.
+Some that aren't even compliant.
+There are configuration options to override the size of standard types.
+There are configuration options to force Unity to not use certain standard library functions.
+A lot of Unity is configurable and we have worked hard to make it not TOO ugly in the process.
 
+Similarly, our tools that parse C do their best.
+They aren't full C parsers (yet) and, even if they were, they would still have to accept non-standard additions like gcc extensions or specifying `@0x1000` to force a variable to compile to a particular location.
+It's just what we do, because we like everything to Just Work™.
+
+Speaking of having things Just Work™, that's our second philosophy.
+By that, we mean that we do our best to have EVERY configuration option have a logical 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 a bit of effort into
-finding *What Something WANTS to be Called*™.
+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 a bit of effort into finding *What Something WANTS to be Called*™.
+
+When naming things, we follow this hierarchy, the first being the most important to us (but we do all four when possible):
 
-When naming things, we follow this hierarchy, the first being the
-most important to us (but we do all four when possible):
 1. Readable
 2. Descriptive
 3. Consistent
 4. Memorable
 
+### Readable
 
-#### 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).
 
-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
+### 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
-longer than the average. Guilty. We're okay with a bit more typing if it
-means our code is easier to understand.
-
-There are two exceptions to this rule that we also stick to as religiously as
-possible:
-
-First, while we realize hungarian notation (and similar systems for encoding
-type information into variable names) is providing a more descriptive name, we
-feel that (for the average developer) it takes away from readability and is to be avoided.
+Finding the right name for something is an important endeavour.
+You might notice from poking around our code that this often results in names that are a little longer than the average.
+Guilty.
+We're okay with a bit more typing if it means our code is easier to understand.
 
-Second, loop counters and other local throw-away variables often have a purpose
-which is obvious. There's no need, therefore, to get carried away with complex
-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.
+There are two exceptions to this rule that we also stick to as religiously as possible:
 
+First, while we realize hungarian notation (and similar systems for encoding type information into variable names) is providing a more descriptive name, we feel that (for the average developer) it takes away from readability and is to be avoided.
 
-#### Consistent
+Second, loop counters and other local throw-away variables often have a purpose which is obvious.
+There's no need, therefore, to get carried away with complex 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.
 
-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.
+### 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
-out in our memory and are easier to search for. Take a look through the file
-names in Ceedling and you'll get a good idea of what we are talking about here.
-Why use preprocess when you can use preprocessinator? Or what better describes a
-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.
+### 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 out in our memory and are easier to search for.
+Take a look through the file names in Ceedling and you'll get a good idea of what we are talking about here.
+Why use preprocess when you can use preprocessinator?
+Or what better describes a module in charge of invoking tasks during releases than release_invoker?
+Don't get carried away.
+The names are still descriptive and fulfil 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
-happy.
-
-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.
+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 happy.
 
+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
+### Whitespace in C/C++
 
-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
-arguments or whatnot). When that happens, we like to indent further to line
-things up in nice tidy columns.
+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 arguments or whatnot).
+When that happens, we like to indent further to line things up in nice tidy columns.
 
 ```C
     if (stuff_happened)
@@ -139,8 +119,7 @@ things up in nice tidy columns.
     }
 ```
 
-
-#### Case
+### Case in C/C++
 
 - Files - all lower case with underscores.
 - Variables - all lower case with underscores
@@ -149,12 +128,12 @@ things up in nice tidy columns.
 - Functions - camel cased. Usually named ModuleName_FuncName
 - Constants and Globals - camel cased.
 
+### Braces in C/C++
 
-#### 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.
+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.
 
 ```C
     while (blah)
@@ -163,32 +142,32 @@ catching an error and you have a one-line, go ahead and to it on the same line.
     }
 ```
 
+### Comments in C/C++
 
-#### 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.
-
+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!
-
+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
+### Whitespace in Ruby
 
-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.
+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
+### Case in Ruby
 
 - Files - all lower case with underscores.
 - Variables - all lower case with underscores
@@ -196,11 +175,13 @@ that happens, we like to indent further to line things up in nice tidy columns.
 - Functions - all lower case with underscores
 - Constants - all upper case with underscores
 
-
 ## Documentation
 
-Egad. Really? We use mark down and we like pdf files because they can be made to
-look nice while still being portable. Good enough?
+Egad.
+Really?
+We use markdown and we like PDF files because they can be made to look nice while still being portable.
+Good enough?
 
+*Find The Latest of This And More at [ThrowTheSwitch.org][]*
 
-*Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*
+[ThrowTheSwitch.org]: https://throwtheswitch.org