Merge pull request #2379 from JordanMaples/patch-6

Add C++CoreGuidelines link to C26407

Author: Colin Robertson

docs/code-quality/c26407.md

@@ -1,24 +1,24 @@
 ---
 title: C26407
-ms.date: 07/21/2017
+ms.date: 08/18/2020
 ms.topic: "conceptual"
 f1_keywords: ["C26407"]
 helpviewer_keywords: ["C26407"]
 ms.assetid: 5539907a-bfa0-40db-82a6-b860c97209e1
 ---
 # C26407 DONT_HEAP_ALLOCATE_UNNECESSARILY
 
-To avoid unnecessary use of pointers we try to detect common patterns of local allocations, for example when the result of a call to operator new is stored in a local variable and later explicitly deleted. This supports the rule R.5: *Prefer scoped objects, don't heap-allocate unnecessarily*. The suggested fix is to use an RAII type instead of a raw pointer and allow it to deal with resources. If an allocation is a single object, then it may be obviously unnecessary and a local variable of the object’s type would work better.
+To avoid unnecessary use of pointers, we try to detect common patterns of local allocations. For example, we detect when the result of a call to operator **`new`** is stored in a local variable and later explicitly deleted. This supports the [C++ Core Guidelines rule R.5](https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#r5-prefer-scoped-objects-dont-heap-allocate-unnecessarily): *Prefer scoped objects, don't heap-allocate unnecessarily*. To fix the issue, use an RAII type instead of a raw pointer, and allow it to deal with resources. Obviously, it isn't necessary to create a wrapper type to allocate a single object. Instead, a local variable of the object's type would work better.
 
 ## Remarks
 
-- To reduce the number of warnings, this pattern is detected for owner pointers only. So, it is necessary to mark owners properly first. We can easily extend this to cover raw pointers if we receive feedback from customers in support of such scenario.
+- To reduce the number of warnings, code analysis only detects this pattern for owner pointers. So, it's necessary to mark owners properly first. We can easily extend this to cover raw pointers if we receive [feedback](https://developercommunity.visualstudio.com/spaces/62/index.html) from customers in support of such scenarios.
 
-- The scoped object term may be a bit misleading, but the general idea is that we suggest using either a local variable whose lifetime is automatically managed, or a smart object which efficiently manages dynamic resources. Smart objects can of course do heap allocations, but it is not explicit in the code.
+- The *scoped object* term may be a bit misleading. In general, we suggest you use either a local variable whose lifetime is automatically managed, or a smart object that efficiently manages dynamic resources. Smart objects can of course do heap allocations, but it's not explicit in the code.
 
-- If the warning fires on array allocation (which is usually needed for dynamic buffers), the fix can be to use standard containers, or `std::unique_pointer<T[]>`.
+- If the warning fires on array allocation, (which is usually needed for dynamic buffers), you can fix it by using standard containers, or `std::unique_pointer<T[]>`.
 
-- The pattern is detected only for local variables, so we don’t warn on cases where an allocation is assigned to, say, a global variable and then deleted in the same function.
+- The pattern is detected only for local variables. We don’t warn in cases where an allocation is assigned to, say, a global variable and then deleted in the same function.
 
 ## Example 1: Unnecessary object allocation on heap