Fix formatting in AdvancedGuide.md

Put occurrences of "#include" in a code span so they are not interpreted
as headers.

Other documents were not broken because the #include was not at the
start of the line, but put them in code spans anyway just in case the
text gets refilled in the future.

12 files changed, 17 insertions, 17 deletions

diff --git a/googlemock/docs/ForDummies.md b/googlemock/docs/ForDummies.md
index e2f362a6..0da4cbe2 100644
--- a/googlemock/docs/ForDummies.md
+++ b/googlemock/docs/ForDummies.md
@@ -44,7 +44,7 @@ We encourage you to use Google Mock as:
   * a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators.
 
 # Getting Started #
-Using Google Mock is easy! Inside your C++ source file, just #include `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
+Using Google Mock is easy! Inside your C++ source file, just `#include` `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
 
 # A Case for Mock Turtles #
 Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface:
diff --git a/googlemock/docs/v1_5/ForDummies.md b/googlemock/docs/v1_5/ForDummies.md
index f389606c..fcc3b561 100644
--- a/googlemock/docs/v1_5/ForDummies.md
+++ b/googlemock/docs/v1_5/ForDummies.md
@@ -44,7 +44,7 @@ We encourage you to use Google Mock as:
   * a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators.
 
 # Getting Started #
-Using Google Mock is easy! Inside your C++ source file, just #include `<gtest/gtest.h>` and `<gmock/gmock.h>`, and you are ready to go.
+Using Google Mock is easy! Inside your C++ source file, just `#include` `<gtest/gtest.h>` and `<gmock/gmock.h>`, and you are ready to go.
 
 # A Case for Mock Turtles #
 Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface:
diff --git a/googlemock/docs/v1_6/ForDummies.md b/googlemock/docs/v1_6/ForDummies.md
index 0891b8c4..19ee63ab 100644
--- a/googlemock/docs/v1_6/ForDummies.md
+++ b/googlemock/docs/v1_6/ForDummies.md
@@ -44,7 +44,7 @@ We encourage you to use Google Mock as:
   * a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators.
 
 # Getting Started #
-Using Google Mock is easy! Inside your C++ source file, just #include `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
+Using Google Mock is easy! Inside your C++ source file, just `#include` `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
 
 # A Case for Mock Turtles #
 Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface:
diff --git a/googlemock/docs/v1_7/ForDummies.md b/googlemock/docs/v1_7/ForDummies.md
index 2ed43007..ee03c5b9 100644
--- a/googlemock/docs/v1_7/ForDummies.md
+++ b/googlemock/docs/v1_7/ForDummies.md
@@ -44,7 +44,7 @@ We encourage you to use Google Mock as:
   * a _testing_ tool to cut your tests' outbound dependencies and probe the interaction between your module and its collaborators.
 
 # Getting Started #
-Using Google Mock is easy! Inside your C++ source file, just #include `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
+Using Google Mock is easy! Inside your C++ source file, just `#include` `"gtest/gtest.h"` and `"gmock/gmock.h"`, and you are ready to go.
 
 # A Case for Mock Turtles #
 Let's look at an example. Suppose you are developing a graphics program that relies on a LOGO-like API for drawing. How would you test that it does the right thing? Well, you can run it and compare the screen with a golden screen snapshot, but let's admit it: tests like this are expensive to run and fragile (What if you just upgraded to a shiny new graphics card that has better anti-aliasing? Suddenly you have to update all your golden images.). It would be too painful if all your tests are like this. Fortunately, you learned about Dependency Injection and know the right thing to do: instead of having your application talk to the drawing API directly, wrap the API in an interface (say, `Turtle`) and code to that interface:
diff --git a/googletest/README.md b/googletest/README.md
index e0ea1b0f..edd44080 100644
--- a/googletest/README.md
+++ b/googletest/README.md
@@ -221,7 +221,7 @@ your build script.
 ### Avoiding Macro Name Clashes ###
 
 In C++, macros don't obey namespaces.  Therefore two libraries that
-both define a macro of the same name will clash if you #include both
+both define a macro of the same name will clash if you `#include` both
 definitions.  In case a Google Test macro clashes with another
 library, you can force Google Test to rename its macro to avoid the
 conflict.
diff --git a/googletest/docs/AdvancedGuide.md b/googletest/docs/AdvancedGuide.md
index 4c4ecb5c..7ba8d121 100644
--- a/googletest/docs/AdvancedGuide.md
+++ b/googletest/docs/AdvancedGuide.md
@@ -1450,7 +1450,7 @@ two cases to consider:
 
 Both static functions and definitions/declarations in an unnamed namespace are
 only visible within the same translation unit. To test them, you can `#include`
-the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc`
+the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc`
 files is not a good way to reuse code - you should not do this in production
 code!)
 
@@ -1551,8 +1551,8 @@ exception, you could catch the exception and assert on it.  But Google
 Test doesn't use exceptions, so how do we test that a piece of code
 generates an expected failure?
 
-`"gtest/gtest-spi.h"` contains some constructs to do this.  After
-#including this header, you can use
+`"gtest/gtest-spi.h"` contains some constructs to do this.  After 
+`#include`ing this header, you can use
 
 | `EXPECT_FATAL_FAILURE(`_statement, substring_`);` |
 |:--------------------------------------------------|
diff --git a/googletest/docs/FAQ.md b/googletest/docs/FAQ.md
index 639c2509..5fd6cb72 100644
--- a/googletest/docs/FAQ.md
+++ b/googletest/docs/FAQ.md
@@ -994,7 +994,7 @@ you can use the _horrible_ hack of sniffing your executable name
 ## Google Test defines a macro that clashes with one defined by another library. How do I deal with that? ##
 
 In C++, macros don't obey namespaces.  Therefore two libraries that
-both define a macro of the same name will clash if you #include both
+both define a macro of the same name will clash if you `#include` both
 definitions.  In case a Google Test macro clashes with another
 library, you can force Google Test to rename its macro to avoid the
 conflict.
diff --git a/googletest/docs/V1_5_AdvancedGuide.md b/googletest/docs/V1_5_AdvancedGuide.md
index 9511f226..34e19c26 100644
--- a/googletest/docs/V1_5_AdvancedGuide.md
+++ b/googletest/docs/V1_5_AdvancedGuide.md
@@ -1365,7 +1365,7 @@ two cases to consider:
 
 Both static functions and definitions/declarations in an unnamed namespace are
 only visible within the same translation unit. To test them, you can `#include`
-the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc`
+the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc`
 files is not a good way to reuse code - you should not do this in production
 code!)
 
@@ -1467,7 +1467,7 @@ Test doesn't use exceptions, so how do we test that a piece of code
 generates an expected failure?
 
 `<gtest/gtest-spi.h>` contains some constructs to do this.  After
-#including this header, you can use
+`#include`ing this header, you can use
 
 | `EXPECT_FATAL_FAILURE(`_statement, substring_`);` |
 |:--------------------------------------------------|
diff --git a/googletest/docs/V1_6_AdvancedGuide.md b/googletest/docs/V1_6_AdvancedGuide.md
index 5225341a..78864b16 100644
--- a/googletest/docs/V1_6_AdvancedGuide.md
+++ b/googletest/docs/V1_6_AdvancedGuide.md
@@ -1447,7 +1447,7 @@ two cases to consider:
 
 Both static functions and definitions/declarations in an unnamed namespace are
 only visible within the same translation unit. To test them, you can `#include`
-the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc`
+the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc`
 files is not a good way to reuse code - you should not do this in production
 code!)
 
@@ -1549,7 +1549,7 @@ Test doesn't use exceptions, so how do we test that a piece of code
 generates an expected failure?
 
 `"gtest/gtest-spi.h"` contains some constructs to do this.  After
-#including this header, you can use
+`#include`ing this header, you can use
 
 | `EXPECT_FATAL_FAILURE(`_statement, substring_`);` |
 |:--------------------------------------------------|
diff --git a/googletest/docs/V1_6_FAQ.md b/googletest/docs/V1_6_FAQ.md
index 6d5d128a..2b7f7840 100644
--- a/googletest/docs/V1_6_FAQ.md
+++ b/googletest/docs/V1_6_FAQ.md
@@ -989,7 +989,7 @@ you can use the _horrible_ hack of sniffing your executable name
 ## Google Test defines a macro that clashes with one defined by another library. How do I deal with that? ##
 
 In C++, macros don't obey namespaces.  Therefore two libraries that
-both define a macro of the same name will clash if you #include both
+both define a macro of the same name will clash if you `#include` both
 definitions.  In case a Google Test macro clashes with another
 library, you can force Google Test to rename its macro to avoid the
 conflict.
diff --git a/googletest/docs/V1_7_AdvancedGuide.md b/googletest/docs/V1_7_AdvancedGuide.md
index 83a8f798..dd4af8f3 100644
--- a/googletest/docs/V1_7_AdvancedGuide.md
+++ b/googletest/docs/V1_7_AdvancedGuide.md
@@ -1448,7 +1448,7 @@ two cases to consider:
 
 Both static functions and definitions/declarations in an unnamed namespace are
 only visible within the same translation unit. To test them, you can `#include`
-the entire `.cc` file being tested in your `*_test.cc` file. (#including `.cc`
+the entire `.cc` file being tested in your `*_test.cc` file. (`#include`ing `.cc`
 files is not a good way to reuse code - you should not do this in production
 code!)
 
@@ -1550,7 +1550,7 @@ Test doesn't use exceptions, so how do we test that a piece of code
 generates an expected failure?
 
 `"gtest/gtest-spi.h"` contains some constructs to do this.  After
-#including this header, you can use
+`#include`ing this header, you can use
 
 | `EXPECT_FATAL_FAILURE(`_statement, substring_`);` |
 |:--------------------------------------------------|
diff --git a/googletest/docs/V1_7_FAQ.md b/googletest/docs/V1_7_FAQ.md
index ded1a48b..3dd914dc 100644
--- a/googletest/docs/V1_7_FAQ.md
+++ b/googletest/docs/V1_7_FAQ.md
@@ -989,7 +989,7 @@ you can use the _horrible_ hack of sniffing your executable name
 ## Google Test defines a macro that clashes with one defined by another library. How do I deal with that? ##
 
 In C++, macros don't obey namespaces.  Therefore two libraries that
-both define a macro of the same name will clash if you #include both
+both define a macro of the same name will clash if you `#include` both
 definitions.  In case a Google Test macro clashes with another
 library, you can force Google Test to rename its macro to avoid the
 conflict.