diff --git a/README.md b/README.md
index 74432905eaf4..cc34a8b4f96c 100644
--- a/README.md
+++ b/README.md
@@ -10,7 +10,7 @@ AnyKernel2 pushes the format even further by allowing kernel developers to modif
 A working script based on DirtyV Kernel for Galaxy Nexus (tuna) is included for reference.
 
 ## // Properties / Variables ##
-```bash
+```
 kernel.string=KernelName by YourName @ xda-developers
 do.devicecheck=1
 do.initd=1
@@ -20,19 +20,18 @@ device.name1=maguro
 device.name2=toro
 device.name3=toroplus
 block=/dev/block/platform/omap/omap_hsmmc.0/by-name/boot;
+```
 
-do.devicecheck=1 specified requires at least device.name1 to be present. This should match ro.product.device or ro.build.product for your device. There is support for up to 5 device.name# properties.
+__do.devicecheck=1__ specified requires at least device.name1 to be present. This should match ro.product.device or ro.build.product for your device. There is support for up to 5 device.name# properties.
 
-do.initd=1 will create the init.d directory in /system/etc/init.d/ and apply 755 permissions.
+__do.initd=1__ will create the init.d directory in /system/etc/init.d/ and apply 755 permissions.
 
-do.modules=1 will push the contents of the module directory to /system/lib/modules/ and apply 644 permissions.
+__do.modules=1__ will push the contents of the module directory to /system/lib/modules/ and apply 644 permissions.
 
-do.cleanup=0 will keep the zip from removing it's working directory in /tmp/anykernel - this can be useful if trying to debug in adb shell whether the patches worked correctly. 
-```
+__do.cleanup=0__ will keep the zip from removing it's working directory in /tmp/anykernel - this can be useful if trying to debug in adb shell whether the patches worked correctly. 
 
 ## // Command Methods ##
-
-```bash
+```
 dump_boot
 backup_file <file>
 replace_string <file> <if search string> <original string> <replacement string>
@@ -49,27 +48,27 @@ patch_fstab <fstab file> <mount match name> <fs match type> <block|mount|fstype|
 write_boot
 ```
 
-"if search string" is the string it looks for to decide whether it needs to add the tweak or not, so generally something to indicate the tweak already exists.
+__"if search string"__ is the string it looks for to decide whether it needs to add the tweak or not, so generally something to indicate the tweak already exists.
 
-Similarly, "line match string" and "line replace string" are the search strings that locate where the modification needs to be made for those commands, "begin search string" and "end search string" are both required to select the first and last lines of the script block to be replaced for replace_section, and "mount match name" and "fs match type" are both required to narrow the patch_fstab command down to the correct entry.
+Similarly, __"line match string"__ and __"line replace string"__ are the search strings that locate where the modification needs to be made for those commands, __"begin search string"__ and __"end search string"__ are both required to select the first and last lines of the script block to be replaced for replace_section, and __"mount match name"__ and __"fs match type"__ are both required to narrow the _patch_fstab_ command down to the correct entry.
 
-"before|after" requires you simply specify "before" or "after" for the placement of the inserted line, in relation to "line match string".
+__"before|after"__ requires you simply specify __"before"__ or __"after"__ for the placement of the inserted line, in relation to __"line match string"__.
 
-"block|mount|fstype|options|flags" requires you specify which part (listed in order) of the fstab entry you want to check and alter.
+__"block|mount|fstype|options|flags"__ requires you specify which part (listed in order) of the fstab entry you want to check and alter.
 
-You may also use ui_print "<text>" to write messages back to the recovery during the modification process, and contains "<string>" "<substring>" to simplify string testing logic you might want in your script.
+You may also use _ui_print "\<text\>"_ to write messages back to the recovery during the modification process, and _contains "\<string\>" "\<substring\>"_ to simplify string testing logic you might want in your script.
 
 ## // Instructions ##
 
-1- Place zImage in the root (dtb should also go here for devices that require a custom one, both will fallback to the original if not included)
+1. Place zImage in the root (dtb should also go here for devices that require a custom one, both will fallback to the original if not included)
 
-2- Place any required ramdisk files in /ramdisk
+2. Place any required ramdisk files in /ramdisk
 
-3- Place any required patch files (generally partial files which go with commands) in /patch
+3. Place any required patch files (generally partial files which go with commands) in /patch
 
-4- Modify the anykernel.sh to add your kernel's name, boot partition location, permissions for included ramdisk files, and use methods for any required ramdisk modifications
+4. Modify the anykernel.sh to add your kernel's name, boot partition location, permissions for included ramdisk files, and use methods for any required ramdisk modifications
 
-5- zip -r9 UPDATE-AnyKernel2.zip * -x README UPDATE-AnyKernel2.zip
+5. zip -r9 UPDATE-AnyKernel2.zip * -x README UPDATE-AnyKernel2.zip
 
 If supporting a recovery that forces zip signature verification (like Cyanogen Recovery) then you will need to also sign your zip using the method I describe here: