@@ -15,11 +15,11 @@ helpviewer_keywords: ["C26441"]
 
 ## Remarks
 
-The standard library provides locks to help control concurrent access to resources during their lifetime. When you declare a lock object without a name, the compiler creates a temporary object that's immediately destructed rather than one that lives to the end of the enclosing scope. So, failure to assign a lock object to a variable is a mistake that effectively disables the locking mechanism (because temporary variables are transient). This rule tries to catch simple cases of such unintended behavior.
+The standard library provides locks to help control concurrent access to resources during their lifetime. When you declare a lock object without a name, the compiler creates a temporary object that's immediately destructed rather than one that lives to the end of the enclosing scope. So, failure to assign a lock object to a variable is a mistake that effectively disables the locking mechanism (because temporary variables are transient). This rule catches simple cases of such unintended behavior.
 
 This diagnostic only analyzes the standard lock types `std::scoped_lock`, `std::unique_lock`, and `std::lock_guard`. Other unnamed RAII types are covered by [C26444](c26444.md).
 
-Only simple calls to constructors are analyzed. More complex initializer expressions may lead to inaccurate results, but it's an unusual scenario. Locks passed as arguments to function calls or returned as results of function calls are ignored. To provide similar protection for types returned by a function call, annotate them with `[[nodiscard]]`. Locks created as temporaries but assigned to named references to extend their lifetime are ignored.
+Only simple calls to constructors are analyzed. More complex initializer expressions may lead to inaccurate results in the form of missed warnings. Locks passed as arguments to function calls or returned as results of function calls are ignored because the analysis tool is unable to determine if those locks are deliberately trying to protect that function call or if they should be extended. To provide similar protection for types returned by a function call, annotate them with `[[nodiscard]]`. Locks created as temporaries but assigned to named references to extend their lifetime are ignored.
 
 Code analysis name: `NO_UNNAMED_GUARDS`
 
 
@@ -19,7 +19,7 @@ If the initialization behavior is by design, then the warning is likely caused b
 
 ### Fix by changes to parameter annotations
 
-If the parameter is expected to already be in an initialized state and the function conditionally modifies it, then the `_Inout_` annotation may be more appropriate. Another option is to use lower level annotations such as `_Pre_null_`, `_Pre_satisfies_()`, and `_Post_satisfies_()` that provide extra flexibility and control over the expected state of the parameter. For more information on parameter annotations, see [Annotating function parameters and return values](./annotating-function-parameters-and-return-values.md).
+If the parameter is expected to already be in an initialized state and the function conditionally modifies it, then the `_Inout_` annotation may be more appropriate. If no other high level annotation fits the intended behavior then you can use a low level annotations such as `_Pre_null_`, `_Pre_satisfies_()`, and `_Post_satisfies_()` that provide extra flexibility and control over the expected state of the parameter. For more information on parameter annotations, see [Annotating function parameters and return values](./annotating-function-parameters-and-return-values.md).
 
 ### Fix by defining successful return paths