Added formatting example to CONTRIBUTE

As above, plus small formatting correction in README.

Author: Chris Massey

Diff for: CONTRIBUTE.md

@@ -8,6 +8,15 @@ By submitting suggestions and changes to the book, you agree to the LICENSE of t
 If you have a new SQL code smell you think we should include, or have suggestions for how to improve one that we've already listed, please do send us your pull request!
 
 ##Formatting
->ToDo
+
+Example from [Problems with Database Design](README.md#Problems_with_Database_Design)
+
+```
+[...]
+#Problems with Database Design <a name="Problems_With_Database_Design"></a>
+##1) Packing lists, complex data, or other multivariate attributes into a table column
+
+It is permissible to put a list or data document in a column only if it is, from the database perspective, ‘atomic’, that is, never likely to be shredded into individual values; in other words...
+```
 
 That's it!

Diff for: README.md

@@ -38,14 +38,13 @@ In describing all these 119 code-smells in a booklet, I’ve been very constrain
 It is permissible to put a list or data document in a column only if it is, from the database perspective, ‘atomic’, that is, never likely to be shredded into individual values; in other words, as long as the value remains in the format in which it started. We store strings, after all, and a string is hardly atomic since it consists of an ordinally significant collection of characters or words. A list or XML value stored in a column, whether by character map, bitmap or XML data type, can be a useful temporary expedient during development, but the column will likely need to be normalized if values will have to be shredded.
 
 A related code smell is:
-###Using inappropriate data types
 
+###Using inappropriate data types
 Although a business may choose to represent a date as a single string of numbers or require codes that mix text with numbers, it is unsatisfactory to store such data in columns that don’t match the actual data type. This confuses the presentation of data with its storage. Dates, money, codes and other business data can be represented in a human-readable form, the ‘presentation’ mode, they can be represented in their storage form, or in their data-interchange form. 
 
 Storing data in the wrong form as strings leads to major issues with coding, indexing, sorting, and other operations. Put the data into the appropriate ‘storage’ data type at all times.
 
 ##2) Storing the hierarchy structure in the same table as the entities that make up the hierarchy
-
 Self-referencing tables seem like an elegant way to represent hierarchies. However, such an approach
 mixes relationships and values. Real-life hierarchies need more than a parent-child relationship. The ‘Closure Table’ pattern, where the relationships are held in a table separate from the data, is much more suitable for real-life hierarchies. Also, in real life, relationships tend have a beginning and an end, and this often needs to be recorded. The HIERARCHYID data type and the common language runtime (CLR) SqlHierarchyId class are provided to make tree structures represented by self-referencing tables more efficient, but they are likely to be appropriate for only a minority of applications.