diff --git a/docs/coding-style.md b/docs/coding-style.md
index 9df3294..2d778cf 100644
--- a/docs/coding-style.md
+++ b/docs/coding-style.md
@@ -1,23 +1,24 @@
+# Coding style for autotest in Chrome OS / Android / Brillo
 These rules are fairly standard and boring. People will bitch about something
 in here, no doubt. Get over it. Much of this was stolen from the Linux Kernel
 coding style, because most of it makes good sense. If you disagree, that's OK,
 but please stick to the rules anyway ;-)
 
 
-Language
+## Language
 
 Please use Python where possible. It's not the ideal language for everything,
 but it's pretty good, and consistency goes a long way in making the project
 maintainable. (Obviously using C or whatever for writing tests is fine).
 
 
-Base coding style
+## Base coding style
 
 When writing python code, unless otherwise stated, stick to the python style
 guide (http://www.python.org/dev/peps/pep-0008/).
 
 
-Indentation & whitespace
+## Indentation & whitespace
 
 Format your code for an 80 character wide screen.
 
@@ -26,6 +27,7 @@
 
 For hanging indentation, use 8 spaces plus all args should be on the new line.
 
+```
      # Either of the following hanging indentation is considered acceptable.
 YES: return 'class: %s, host: %s, args = %s' % (
              self.__class__.__name__, self.hostname, self.args)
@@ -42,6 +44,7 @@
      # Do put all args on new line
 NO:  return 'class: %s, host: %s, args = %s' % (self.__class__.__name__,
              self.hostname, self.args)
+```
 
 Don't leave trailing whitespace, or put whitespace on blank lines.
 
@@ -49,17 +52,17 @@
 function end markers, and we need help.
 
 
-Variable names and UpPeR cAsE
+## Variable names and UpPeR cAsE
 
 Use descriptive variable names where possible - it helps to make the code
 self documenting.
 
 Don't use CamelCaps style in most places - use underscores to separate parts
-of your variable_names please. I shall make a bedgrudging exception for class
+of your variable\_names please. I shall make a bedgrudging exception for class
 names I suppose, but I'll still whine about it a lot.
 
 
-Importing modules
+## Importing modules
 
 The order of imports should be as follows:
 
@@ -70,14 +73,23 @@
 Within one of these three sections, all module imports using the from
 keyword should appear after regular imports.
 Each module should be imported on its own line.
-Wildcard imports (from x import *) should be avoided if possible.
+Wildcard imports (from x import \*) should be avoided if possible.
 Classes should not be imported from modules, but modules may be imported
  from packages, i.e.:
+
+```
 from common_lib import error
-and not
+```
+
+and not:
+
+```
 from common_lib.error import AutoservError
+```
 
 For example:
+
+```
 import os
 import pickle
 import random
@@ -91,16 +103,16 @@
 import MySQLdb  # After common so that we check our site-packages first.
 
 from common_lib import error
+```
 
-
-Testing None
+## Testing None
 
 Use "is None" rather than "== None" and "is not None" rather than "!= None".
-This way you'll never run into a case where someone's __eq__ or __ne__
+This way you'll never run into a case where someone's `__eq__` or `__ne__`
 method do the wrong thing
 
 
-Comments
+## Comments
 
 Generally, you want your comments to tell WHAT your code does, not HOW.
 We can figure out how from the code itself (or if not, your code needs fixing).
@@ -111,17 +123,19 @@
 incredibly helpful in understanding code.
 
 
-Hardcoded String Formatting
+## Hardcoded String Formatting
 
 Strings should use only single quotes for hardcoded strings in the code. Double
 quotes are acceptable when single quote is used as part of the string.
 Multiline string should not use '\' but wrap the string using parenthesises.
 
+```
 REALLY_LONG_STRING = ('This is supposed to be a really long string that is '
                       'over 80 characters and does not use a slash to '
                       'continue.')
+```
 
-Docstrings
+## Docstrings
 
 Docstrings are important to keep our code self documenting. While it's not
 necessary to overdo documentation, we ask you to be sensible and document any
@@ -133,6 +147,7 @@
 multiple lines, put two levels of indentation before proceeding with text. An
 example docstring:
 
+```
 def foo(param1, param2):
     """
     Summary line.
@@ -148,6 +163,7 @@
     @raises exception that could be raised if a certain condition occurs.
 
     """
+```
 
 The tags that you can put inside your docstring are tags recognized by systems
 like doxygen. Not all places need all tags defined, so choose them wisely while
@@ -169,7 +185,7 @@
 
 When in doubt refer to: http://doxygen.nl/commands.html
 
-Simple code
+## Simple code
 
 Keep it simple; this is not the right place to show how smart you are. We
 have plenty of system failures to deal with without having to spend ages
@@ -181,7 +197,7 @@
 smart enough to debug it."  Brian Kernighan
 
 
-Function length
+## Function length
 
 Please keep functions short, under 30 lines or so if possible. Even though
 you are amazingly clever, and can cope with it, the rest of us are all stupid,
@@ -192,22 +208,24 @@
 as we all know), and do one thing and do that well.
 
 
-Exceptions
+## Exceptions
 
 When raising exceptions, the preferred syntax for it is:
 
+```
 raise FooException('Exception Message')
+```
 
 Please don't raise string exceptions, as they're deprecated and will be removed
 from future versions of python. If you're in doubt about what type of exception
 you will raise, please look at http://docs.python.org/lib/module-exceptions.html
-and client/common_lib/error.py, the former is a list of python built in
+and client/common\_lib/error.py, the former is a list of python built in
 exceptions and the later is a list of autotest/autoserv internal exceptions. Of
 course, if you really need to, you can extend the exception definitions on
-client/common_lib/error.py.
+client/common\_lib/error.py.
 
 
-Submitting patches
+## Submitting patches
 
 Generate universal diffs. Email them to autotest@test.kernel.org.
 Most mailers now break lines and/or changes tabs to spaces. If you know how