edit pass: header-unit-walkthroughs

Author: v-albemi

docs/build/walkthrough-header-units.md

@@ -26,15 +26,13 @@ An important difference between a header unit and a header file is that header u
 
 A similarity is that everything visible from a header file is also visible from a header unit.
 
-Before you can import a header unit, you need to compile a header file into a header unit. An advantage of header units over PCH is that they can be used in distributed builds. For example, as long as you're using the same compiler to compile the .ifc and the program that imports it and are targeting the same platform and architecture, a header unit produced on one computer can be used on another.
+Before you can import a header unit, you need to compile a header file into a header unit. An advantage of header units over PCH is that they can be used in distributed builds. For example, as long as you're using the same compiler to compile the *`.ifc`* and the program that imports it and are targeting the same platform and architecture, a header unit produced on one computer can be used on another.
 
-Another advantage of header units over PCH is that there's more flexibility for the compiler flags used to compile the header unit and for the program that imports it. With a PCH, more compiler flags must be the same. But with header units, these primary flags should be the same:
+Another advantage of header units over PCH is that there's more flexibility for the compiler flags used to compile the header unit and for the program that imports it. With a PCH, more compiler flags must be the same. But with header units, these flags should be the same:
 
-- Exception handling switches like `/EHsc`
-- `/MD[d]` or `MT[d]`
-- `/D` 
-
-You can define additional macros when you build the program that imports the header unit. But the ones used to build the header unit should also be present and defined the same way when you build the program that imports the header unit.
+- Exception handling switches like `/EHsc`.
+- `/MD[d]` or `MT[d]`.
+- `/D`. You can define additional macros when you build the program that imports the header unit. But the ones used to build the header unit should also be present and defined the same way when you build the program that imports the header unit.
 
 ## Ways to compile a header unit
 
@@ -88,14 +86,14 @@ In **Solution Explorer**, select the file you want to compile as a header unit.
 Set the **Item Type** property to **C/C++ compiler**. By default, header files have an **Item Type** of **C/C++ header**. Setting this property also sets **C/C++** > **Advanced** > **Compile As** to **Compile as C++ Header Unit (/exportHeader)**.
 :::image type="content" source="media/change-item-type.png" alt-text="Screenshot that shows changing the item type to C/C++ compiler.":::
 
-**For source files** (or header files that don't have an .h or .hpp extension):
+**For source files** (or header files that don't have an *`.h`* or *`.hpp`* extension):
 
 Set the **Compile As** property to **Compile as C++ Header Unit (/exportHeader)**.
 :::image type="content" source="media/change-compile-as.png" alt-text="Screenshot that shows changing Compile As to Compile as C++ Header Unit.":::
 
 ### Change your code to import a header unit
 
-In the source file for the example project, that is, the file that contains `main()`, change `#include "Pythagorean.h"` to `import "Pythagorean.h"`. (Don't forget the trailing semicolon that's required for `import` statements.) When you're compiling a header unit from a system header, use angle brackets (`import <file>;`). If it's a project header, use `import "file";`.
+In the source file for the example project, that is, the file that contains `main()`, change `#include "Pythagorean.h"` to `import "Pythagorean.h";`. (Don't forget the trailing semicolon that's required for `import` statements.) When you're compiling a header unit from a system header, use angle brackets (`import <file>;`). If it's a project header, use `import "file";`.
 
 Build the solution. (**Build** > **Build Solution** on the main menu.) Run it to see that it produces the expected output: `Pythagorean triple a:2 b:3 c:13`
 

docs/build/walkthrough-import-stl-header-units.md

@@ -17,7 +17,7 @@ The [second way](#approach2) is to build a static library project that contains
 
 Importing an STL header as a header unit is a simpler alternative to [precompiled header files](creating-precompiled-header-files.md). Header units are easier to set up and use than a shared precompiled header file (PCH) but still provide similar performance benefits. Unlike a PCH, when a header unit changes, only it and its dependencies are rebuilt.
 
-Before you can import an STL header, it must be compiled into a header unit. A header unit is a binary representation of a header file. A header unit ends with an .ifc extension.
+Before you can import an STL header, it must be compiled into a header unit. A header unit is a binary representation of a header file. A header unit ends with an *`.ifc`* extension.
 
 An important difference between a header unit and a header file is that header units aren't affected by macro definitions. You can't `#define` a symbol that causes the header unit to behave differently when you import it. You can do that with a header file.
 
@@ -33,7 +33,7 @@ Before you can import an STL header, it must be compiled into a header unit. The
 
 **Scan for module dependencies**
 
-At a high level, when you use this approach, the build system scans your sources for `import "header";` and `import <header>;` statements. It then attempts to compile those header files and their dependencies into header units. Finally, it imports the compiled header unit files (.ifc) instead of running the header file through the preprocessor.
+At a high level, when you use this approach, the build system scans your sources for `import "header";` and `import <header>;` statements. It then attempts to compile those header files and their dependencies into header units. Finally, it imports the compiled header unit files (*`.ifc`*) instead of running the header file through the preprocessor.
 
 This approach might not be the best one for larger projects because it doesn't guarantee optimal build times. That's because the build system needs to scan through the files to find the headers to build into header units. The same header files might be reprocessed repeatedly, which would increase build time. Also, not all header files can be automatically converted to header units. For example, headers that depend on conditional compilation via `#define` symbols might not work as header units. If a header file can't be compiled into a header unit, it's treated as a normal `#include` file.
 
@@ -206,7 +206,7 @@ These settings control the visibility of header units to the build system:
 
 Typically, the easiest way to reuse header units among solutions is to reference the same shared header unit project from each solution.
 
-But if you need to use a built header unit that you don't have the project for, you can specify where the built .ifc file is so you can import it in your solution.
+But if you need to use a built header unit that you don't have the project for, you can specify where the built *`.ifc`* file is so you can import it in your solution.
 
 To access this setting:
 1. On the main menu, select **Project** > **Properties**. The project properties page opens.