Markdown style fixes for:

code_coverage.md
cocoa_tips_and_tricks.md
closure_compilation.md
clang_format.md
clang_tool_refactoring.md
clang.md

R=nodir
BUG=524256

Review URL: https://codereview.chromium.org/1306233003

Cr-Commit-Position: refs/heads/master@{#345652}
diff --git a/docs/cocoa_tips_and_tricks.md b/docs/cocoa_tips_and_tricks.md
index d13ba68..2ab0329 100644
--- a/docs/cocoa_tips_and_tricks.md
+++ b/docs/cocoa_tips_and_tricks.md
@@ -1,12 +1,16 @@
-# Introduction
+# Cocoa Tips and Tricks
 
-A collection of idioms that we use when writing the Cocoa views and controllers for Chromium.
+A collection of idioms that we use when writing the Cocoa views and controllers
+for Chromium.
+
+[TOC]
 
 ## NSWindowController Initialization
 
-To make sure that |window| and |delegate| are wired up correctly in your xib, it's useful to add this to your window controller:
+To make sure that |window| and |delegate| are wired up correctly in your xib,
+it's useful to add this to your window controller:
 
-```
+```objective-c
 - (void)awakeFromNib {
   DCHECK([self window]);
   DCHECK_EQ(self, [[self window] delegate]);
@@ -15,14 +19,19 @@
 
 ## NSWindowController Cleanup
 
-"You want the window controller to release itself it |-windowDidClose:|, because else it could die while its views are still around. if it (auto)releases itself in the callback, the window and its views are already gone and they won't send messages to the released controller."
+"You want the window controller to release itself it |-windowDidClose:|, because
+else it could die while its views are still around. if it (auto)releases itself
+in the callback, the window and its views are already gone and they won't send
+messages to the released controller."
 - Nico Weber (thakis@)
 
-See [Window Closing Behavior, ADC Reference](http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Documents/Concepts/WindowClosingBehav.html#//apple_ref/doc/uid/20000027) for the full story.
+See
+[Window Closing Behavior, ADC Reference](http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/Documents/Concepts/WindowClosingBehav.html#//apple_ref/doc/uid/20000027)
+for the full story.
 
 What this means in practice is:
 
-```
+```objective-c
 @interface MyWindowController : NSWindowController<NSWindowDelegate> {
   IBOutlet NSButton* closeButton_;
 }
@@ -57,13 +66,20 @@
 
 ## Unit Tests
 
-There are four Chromium-specific GTest macros for writing ObjC++ test cases.  These macros are EXPECT\_NSEQ, EXPECT\_NSNE, and ASSERT variants by the same names.  These test `-[id<NSObject> isEqual:]` and will print the object's `-description` in GTest-style if the assertion fails.  These macros are defined in //testing/gtest\_mac.h.  Just include that file and you can start using them.
+There are four Chromium-specific GTest macros for writing ObjC++ test cases.
+These macros are `EXPECT_NSEQ`, `EXPECT_NSNE`, and `ASSERT` variants by the same
+names.  These test `-[id<NSObject> isEqual:]` and will print the object's
+`-description` in GTest-style if the assertion fails. These macros are defined
+in `//testing/gtest_mac.h`. Just include that file and you can start using them.
 
 This allows you to write this:
+
+```objective-c
+EXPECT_NSEQ(@"foo", aString);
 ```
-  EXPECT_NSEQ(@"foo", aString);
-```
+
 Instead of this:
+
+```objective-c
+EXPECT_TRUE([aString isEqualToString:@"foo"]);
 ```
-  EXPECT_TRUE([aString isEqualToString:@"foo"]);
-```
\ No newline at end of file