1 files changed, 6 insertions, 5 deletions
diff --git a/doc/development/fe_guide/design_anti_patterns.md b/doc/development/fe_guide/design_anti_patterns.md
index 0788921fce4..9e602b1ea04 100644
--- a/doc/development/fe_guide/design_anti_patterns.md
+++ b/doc/development/fe_guide/design_anti_patterns.md
@@ -12,7 +12,8 @@ generally be avoided.
 Throughout the GitLab codebase, there may be historic uses of these anti-patterns. Please [use discretion](https://about.gitlab.com/handbook/engineering/#balance-refactoring-and-velocity)
 when figuring out whether or not to refactor, when touching code that uses one of these legacy patterns.
 
-**Please note:** For new features, anti-patterns are not necessarily prohibited, but it is **strongly suggested** to find another approach.
+NOTE:
+For new features, anti-patterns are not necessarily prohibited, but it is **strongly suggested** to find another approach.
 
 ## Shared Global Object (Anti-pattern)
 
@@ -59,7 +60,7 @@ Shared Global Object's solve the problem of making something globally accessible
 could be appropriate:
 
 - When a responsibility is truly global and should be referenced across the application
-  (e.g., an application-wide Event Bus).
+  (for example, an application-wide Event Bus).
 
 Even in these scenarios, please consider avoiding the Shared Global Object pattern because the
 side-effects can be notoriously difficult to reason with.
@@ -136,8 +137,8 @@ many problems with a module that exports utility functions.
 Singletons solve the problem of enforcing there to be only 1 instance of a thing. It's possible
 that a Singleton could be appropriate in the following rare cases:
 
-- We need to manage some resource that **MUST** have just 1 instance (i.e. some hardware restriction).
-- There is a real [cross-cutting concern](https://en.wikipedia.org/wiki/Cross-cutting_concern) (e.g., logging) and a Singleton provides the simplest API.
+- We need to manage some resource that **MUST** have just 1 instance (that is, some hardware restriction).
+- There is a real [cross-cutting concern](https://en.wikipedia.org/wiki/Cross-cutting_concern) (for example, logging) and a Singleton provides the simplest API.
 
 Even in these scenarios, please consider avoiding the Singleton pattern.
 
@@ -174,7 +175,7 @@ export const fuzzify = (id) => { /* ... */ };
 #### Dependency Injection
 
 [Dependency Injection](https://en.wikipedia.org/wiki/Dependency_injection) is an approach which breaks
-coupling by declaring a module's dependencies to be injected from outside the module (e.g., through constructor parameters, a bona-fide Dependency Injection framework, and even Vue's `provide/inject`).
+coupling by declaring a module's dependencies to be injected from outside the module (for example, through constructor parameters, a bona-fide Dependency Injection framework, and even Vue's `provide/inject`).
 
 ```javascript
 // bad - Vue component coupled to Singleton