Standardize formatting for all quotes

README.md

@@ -148,7 +148,7 @@ This kind of logical progression in our function names, makes the code easier to
 #### Variable Naming
 Rather interestingly, the opposite is true for variables. Unlike functions, our variable naming should progress from more to less specific. 
 
-<p align=center style="margin: 0 100px 20px 100px; font-style: italic">"You shouldn’t name your variables after their types for the same reason you wouldn’t name your pets 'dog' or 'cat'." - Dave Cheney</p>
+> <em>You shouldn’t name your variables after their types for the same reason you wouldn’t name your pets 'dog' or 'cat'. &ndash; Dave Cheney</em>
 
 The reason why we want to become less and less specific with our variables, is the fact that it becomes clearer and clearer for the reader, what the variable represents, the smaller the scope of the variable is. In the example of the previous function `fileExtension`, the naming of the variable `segments`, could even be shortened to `s`, if we wanted to. The context of the variable is so clear, it is unnecessary to explain our code further, with longer variable names. Another good example of this, would be in nested for loops. 
 
@@ -194,9 +194,7 @@ Even though the function might still be readable, due to it's brevity, there is
 ### Cleaning Functions
 #### Function Length
 
-In the words of Robert C. Martin: 
-
-<p align=center style="margin: 0 100px 20px 100px; font-style: italic">"How small should a function be? Smaller than that!"</p>
+> <em>How small should a function be? Smaller than that! &ndash; Robert C. Martin</em>
 
 When writing clean code, our primary goal is to make our code easily digestible. The most effective way to do this, is to make our functions as small as possible. It's important to understand, that this is not necessarily to avoid code duplication. The more prominent reason for this is to heighten the code comprehension. Another way of explaining this, is to look at a function description: 
 
@@ -1055,7 +1053,7 @@ The above function ensures, that the `NullWriter` struct implements the `Writer`
 
 There is another way of trying to be more explicit about which interfaces a given struct implements. However, this method achieves the opposite of what we wish to achieve. The method being, using embedded interfaces, as a struct property.
 
-<p align=center style="font-style: italic">"Wait what?" - Presumably most people</p>
+> <em>Wait what? &ndash; Presumably most people</em>
 
 So, let's rewind a little, before we dive deep into the forbidden forest of smelly Go. In Go, we can use embedded structs, as a type of inheritance in our struct definitions. This is really nice as we can decouple our code, by defining reusable structs.
 
@@ -1158,7 +1156,7 @@ The explanation being, that an interface method in Go, is essentially a function
 
 Let's quickly get back to clean code and quickly get back to using interfaces the proper way in Go. Let's talk about using interfaces as function parameters and return values. The most common proverb for interface usage with functions in Go is:
 
-<p align=center style="font-style: italic; margin: 0 150px 0 150px">"Be conservative in what you do, be liberal in what you accept from others" - Jon Postel</p>
+> <em>Be conservative in what you do; be liberal in what you accept from others &ndash; Jon Postel</em>
 
 > FUN FACT: This proverb originally has nothing to do with Go, but is actually taken from an early specification of the TCP networking protocol.