markdown conformance

docs/ThrowTheSwitchCodingStandard.md

@@ -8,14 +8,12 @@ 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.
 
-
 ## Our Philosophy
 
 Before we get into details on syntax, let's take a moment to talk about our
@@ -46,7 +44,6 @@ 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
@@ -56,20 +53,19 @@ 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):
+
 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).
 
-
-#### 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
@@ -90,16 +86,14 @@ 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
+### 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
+### 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
@@ -108,10 +102,9 @@ 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
+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?
@@ -123,8 +116,7 @@ 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
@@ -139,8 +131,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,8 +140,7 @@ things up in nice tidy columns.
 - Functions - camel cased. Usually named ModuleName_FuncName
 - Constants and Globals - camel cased.
 
-
-#### Braces
+### Braces in C/C++
 
 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
@@ -163,8 +153,7 @@ catching an error and you have a one-line, go ahead and to it on the same line.
     }
 ```
 
-
-#### Comments
+### Comments in C/C++
 
 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,
@@ -172,23 +161,20 @@ 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
+### 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.
 
-
-#### Case
+### Case in Ruby
 
 - Files - all lower case with underscores.
 - Variables - all lower case with underscores
@@ -196,11 +182,9 @@ 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?
 
-
 *Find The Latest of This And More at [ThrowTheSwitch.org](https://throwtheswitch.org)*