Update C++ Core Guideline links

Rageking8 · web-flow · commit 36d1e476bc86 · 2025-05-30T16:55:54.000+08:00
diff --git a/docs/code-quality/c26409.md b/docs/code-quality/c26409.md
@@ -13,7 +13,7 @@ ms.assetid: a3b3a229-d566-4be3-bd28-2876ccc8dc37
 Even if code is clean of calls to `malloc` and `free`, we still suggest that you consider better options than explicit use of operators [`new` and `delete`](../cpp/new-and-delete-operators.md).
 
 **C++ Core Guidelines**:\
-[R.11: Avoid calling new and delete explicitly](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r11-avoid-calling-new-and-delete-explicitly)
+[R.11: Avoid calling `new` and `delete` explicitly](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r11-avoid-calling-new-and-delete-explicitly)
 
 The ultimate fix is to use smart pointers and appropriate factory functions, such as [`std::make_unique`](../standard-library/memory-functions.md#make_unique).
 
diff --git a/docs/code-quality/c26414.md b/docs/code-quality/c26414.md
@@ -11,7 +11,7 @@ ms.assetid: dd875d0c-6752-4491-a533-3e8831795fbc
 > "Move, copy, reassign or reset a local smart pointer."
 
 **C++ Core Guidelines**:\
-[R.5: Prefer scoped objects, don't heap-allocate unnecessarily](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rr-scoped)
+[R.5: Prefer scoped objects, don't heap-allocate unnecessarily](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#r5-prefer-scoped-objects-dont-heap-allocate-unnecessarily)
 
 Smart pointers are convenient for dynamic resource management, but they're not always necessary. For example, it may be easier and more efficient to manage a local dynamic buffer by using a standard container. You may not need dynamic allocation at all for single objects, for example, if they never outlive their creator function. They can be replaced with local variables. Smart pointers become handy when a scenario requires a change of ownership. For example, when you reassign a dynamic resource multiple times, or in multiple paths. They're also useful for resources obtained from external code. And, when smart pointers are used to extend the lifetime of a resource.
 
diff --git a/docs/code-quality/c26432.md b/docs/code-quality/c26432.md
@@ -11,7 +11,7 @@ ms.assetid: f587b05a-5c69-4176-baa6-fcb79d228b24
 > `If you define or delete any default operation in the type 'type-name', define or delete them all (c.21).`
 
 **C++ Core Guidelines**:\
-[C.21: If you define or =delete any default operation, define or =delete them all](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c21-if-you-define-or-delete-any-default-operation-define-or-delete-them-all)
+[C.21: If you define or `=delete` any copy, move, or destructor function, define or `=delete` them all](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#c21-if-you-define-or-delete-any-copy-move-or-destructor-function-define-or-delete-them-all)
 
 Special operations such as constructors are assumed to alter the behavior of types so they rely more on language mechanisms to automatically enforce specific scenarios. The canonical example is resource management. If you explicitly define, default, or delete any of these special operations, it signals you want to avoid any special handling of a type. It's inconsistent to leave the other operations unspecified, that is, implicitly defined as deleted by the compiler.
 
diff --git a/docs/code-quality/c26437.md b/docs/code-quality/c26437.md
@@ -11,7 +11,7 @@ ms.assetid: ed2f55bc-a6d8-4cc4-8069-5c96e581a96a
 > Do not slice.
 
 **C++ Core Guidelines**:
-[ES.63: Don't slice](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-slice)
+[ES.63: Don't slice](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es63-dont-slice)
 
 The language allows [slicing](https://en.wikipedia.org/wiki/Object_slicing) and can be viewed as a special case of a dangerous implicit cast. Even if it's done intentionally and doesn't lead to immediate issues, it's still highly discouraged. It makes code harder to change, by forcing extra requirements on related data types. It's especially true if types are polymorphic or involve resource management.
 
diff --git a/docs/code-quality/c26439.md b/docs/code-quality/c26439.md
@@ -10,7 +10,7 @@ ms.assetid: 9df2a1b0-ea94-4884-9d28-c1522ec33a1b
 
 > This kind of function may not throw. Declare it 'noexcept'.
 
-[**C++ Core Guidelines** F.6](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-noexcept): If your function must not throw, declare it `noexcept`
+[F.6: If your function must not throw, declare it `noexcept`](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f6-if-your-function-must-not-throw-declare-it-noexcept)
 
 Some operations should never throw exceptions. Their implementations should be reliable and should handle possible errors conditions gracefully. They shouldn't use exceptions to indicate failure. This rule flags cases where such operations aren't explicitly marked as `noexcept`, which means that they may throw exceptions and consumers can't make assumptions about its reliability.
 
@@ -64,4 +64,4 @@ struct S
 ## See also
 
 [C26455](./c26455.md)\
-[**C++ Core Guidelines** F.6](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-noexcept)
+[F.6: If your function must not throw, declare it `noexcept`](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f6-if-your-function-must-not-throw-declare-it-noexcept)
diff --git a/docs/code-quality/c26441.md b/docs/code-quality/c26441.md
@@ -11,7 +11,7 @@ helpviewer_keywords: ["C26441"]
 
 ## C++ Core Guidelines
 
-[CP.44](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cp44-remember-to-name-your-lock_guards-and-unique_locks): Remember to name your `lock_guard`s and `unique_lock`s
+[CP.44: Remember to name your `lock_guard`s and `unique_lock`s](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#cp44-remember-to-name-your-lock_guards-and-unique_locks)
 
 ## Remarks
 
diff --git a/docs/code-quality/c26444.md b/docs/code-quality/c26444.md
@@ -11,7 +11,7 @@ helpviewer_keywords: ["C26444"]
 
 ## C++ Core Guidelines
 
-[ES.84: Don't (try to) declare a local variable with no name](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-noname)
+[ES.84: Don't try to declare a local variable with no name](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es84-dont-try-to-declare-a-local-variable-with-no-name)
 
 An unnamed variable declaration creates a temporary object that is discarded at the end of the statement. Such temporary objects with nontrivial behavior may point to either inefficient code that allocates and immediately throws away resources or to the code that unintentionally ignores nonprimitive data. Sometimes it may also indicate plainly wrong declaration.
 
@@ -46,4 +46,4 @@ void Foo()
 ## See also
 
 [C26441](C26441.md)\
-[ES.84: Don't (try to) declare a local variable with no name](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-noname)
+[ES.84: Don't try to declare a local variable with no name](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es84-dont-try-to-declare-a-local-variable-with-no-name)
diff --git a/docs/code-quality/c26449.md b/docs/code-quality/c26449.md
@@ -9,7 +9,7 @@ helpviewer_keywords: ["C26449"]
 
 > `gsl::span` or `std::string_view` created from a temporary will be invalid when the temporary is invalidated (gsl.view)
 
-C++ Core Guidelines: [GSL.view: Views](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#SS-views).
+C++ Core Guidelines: [GSL.view: Views](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#gslview-views).
 
 Spans and views are convenient and lightweight types that allow you to reference memory buffers. But they must be used carefully: while their interface looks similar to standard containers, their behavior is more like the behavior of pointers and references. They don't own data and must never be constructed from temporary buffers. This check focuses on cases where source data is temporary, while a span or view isn't. This rule can help to avoid subtle but dangerous mistakes made when legacy code gets modernized and adopts spans or views. There's another check that handles a slightly different scenario involving span references: [C26445 NO_SPAN_REF](c26445.md). 
 
diff --git a/docs/code-quality/c26450.md b/docs/code-quality/c26450.md
@@ -47,4 +47,4 @@ long long multiply()
 [C26452](c26452.md)\
 [C26453](c26453.md)\
 [C26454](c26454.md)\
-[ES.103: Don't overflow](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-overflow)
+[ES.103: Don't overflow](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es103-dont-overflow)
diff --git a/docs/code-quality/c26452.md b/docs/code-quality/c26452.md
@@ -41,5 +41,5 @@ unsigned long long combine(unsigned lo, unsigned hi)
 [C26451](c26451.md)\
 [C26453](c26453.md)\
 [C26454](c26454.md)\
-[ES.101: Use unsigned types for bit manipulation](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-unsigned)\
-[ES.102: Use signed types for arithmetic](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-signed)
+[ES.101: Use unsigned types for bit manipulation](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es101-use-unsigned-types-for-bit-manipulation)\
+[ES.102: Use signed types for arithmetic](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es102-use-signed-types-for-arithmetic)
diff --git a/docs/code-quality/c26453.md b/docs/code-quality/c26453.md
@@ -43,5 +43,5 @@ void leftshift(int shiftCount)
 [C26451](c26451.md)\
 [C26452](c26452.md)\
 [C26454](c26454.md)\
-[ES.101: Use unsigned types for bit manipulation](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-unsigned)\
-[ES.102: Use signed types for arithmetic](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-signed)
+[ES.101: Use unsigned types for bit manipulation](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es101-use-unsigned-types-for-bit-manipulation)\
+[ES.102: Use signed types for arithmetic](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es102-use-signed-types-for-arithmetic)
diff --git a/docs/code-quality/c26454.md b/docs/code-quality/c26454.md
@@ -41,4 +41,4 @@ unsigned int negativeunsigned()
 [C26451](c26451.md)\
 [C26452](c26452.md)\
 [C26453](c26453.md)\
-[ES.106: Don't try to avoid negative values by using unsigned](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-nonnegative)
+[ES.106: Don't try to avoid negative values by using `unsigned`](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es106-dont-try-to-avoid-negative-values-by-using-unsigned)
diff --git a/docs/code-quality/c26455.md b/docs/code-quality/c26455.md
@@ -24,4 +24,4 @@ Code analysis name: `DEFAULT_CTOR_NOEXCEPT`
 ## See also
 
 [C26439](./c26439.md)\
-[**C++ Core Guidelines** F.6](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-noexcept)
+[F.6: If your function must not throw, declare it `noexcept`](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f6-if-your-function-must-not-throw-declare-it-noexcept)
diff --git a/docs/code-quality/c26478.md b/docs/code-quality/c26478.md
@@ -37,4 +37,4 @@ To fix the issue, remove the redundant `std::move`.
 
 ## See also
 
-[ES.56 - Write `std::move()` only when you need to explicitly move an object to another scope](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-move)
+[ES.56: Write `std::move()` only when you need to explicitly move an object to another scope](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es56-write-stdmove-only-when-you-need-to-explicitly-move-an-object-to-another-scope)
diff --git a/docs/code-quality/c26479.md b/docs/code-quality/c26479.md
@@ -38,5 +38,5 @@ S foo()
 
 ## See also
 
-[F.48 - Don't return `std::move(local)`](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rf-return-move-local)\
-[ES.56 - Write `std::move()` only when you need to explicitly move an object to another scope](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-move)
+[F.48: Don't `return std::move(local)`](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f48-dont-return-stdmovelocal)\
+[ES.56: Write `std::move()` only when you need to explicitly move an object to another scope](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es56-write-stdmove-only-when-you-need-to-explicitly-move-an-object-to-another-scope)
diff --git a/docs/code-quality/c26494.md b/docs/code-quality/c26494.md
@@ -37,5 +37,5 @@ void function()
 
 ## See also
 
-[ES.20: Always initialize an object](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-always)\
-[C++ Core Guidelines Type.5](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#prosafety-type-safety-profile)
+[ES.20: Always initialize an object](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es20-always-initialize-an-object)\
+[Pro.safety: Type-safety profile](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#prosafety-type-safety-profile)
diff --git a/docs/code-quality/c26498.md b/docs/code-quality/c26498.md
@@ -9,7 +9,7 @@ helpviewer_keywords: ["C26498"]
 
 > The function '*function*' is constexpr, mark variable '*variable*' constexpr if compile-time evaluation is desired (con.5)
 
-This rule helps to enforce Con.5 from the [C++ Core Guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rconst-constexpr): use constexpr for values that can be computed at compile time.
+This rule helps to enforce [Con.5: Use `constexpr` for values that can be computed at compile time](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#con5-use-constexpr-for-values-that-can-be-computed-at-compile-time) in the C++ Core Guidelines.
 
 ## Remarks
 
@@ -60,4 +60,4 @@ void foo()
 
 [C26497](./c26407.md)\
 [C26814](./c26814.md)\
-[Con.5](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rconst-constexpr)
+[Con.5: Use `constexpr` for values that can be computed at compile time](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#con5-use-constexpr-for-values-that-can-be-computed-at-compile-time)
diff --git a/docs/code-quality/c26815.md b/docs/code-quality/c26815.md
@@ -78,4 +78,4 @@ void f() {
 ## See also
 
 [C26816](c26816.md)\
-[ES.65: Don't dereference an invalid pointer](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-deref)
+[ES.65: Don't dereference an invalid pointer](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es65-dont-dereference-an-invalid-pointer)
diff --git a/docs/code-quality/c26816.md b/docs/code-quality/c26816.md
@@ -62,4 +62,4 @@ int f() {
 ## See also
 
 [C26815](c26815.md)\
-[ES.65: Don't dereference an invalid pointer](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-deref)
+[ES.65: Don't dereference an invalid pointer](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es65-dont-dereference-an-invalid-pointer)
diff --git a/docs/code-quality/c26817.md b/docs/code-quality/c26817.md
@@ -9,7 +9,7 @@ helpviewer_keywords: ["C26817"]
 
 > Potentially expensive copy of variable *name* in range-for loop. Consider making it a const reference (es.71).
 
-For more information, see [ES.71 notes](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-for-range) in the C++ Core Guidelines.
+For more information, see [ES.71: Prefer a range-`for`-statement to a `for`-statement when there is a choice](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es71-prefer-a-range-for-statement-to-a-for-statement-when-there-is-a-choice) in the C++ Core Guidelines.
 
 ## Example
 
diff --git a/docs/code-quality/c26819.md b/docs/code-quality/c26819.md
@@ -13,7 +13,7 @@ helpviewer_keywords: ["C26819"]
 
 This check covers implicit fallthrough in switch statements. Implicit fallthrough is when control flow transfers from one switch case directly into a following switch case without the use of the `[[fallthrough]];` statement. This warning is raised when an implicit fallthrough is detected in a switch case containing at least one statement.
 
-For more information, see [ES.78: Don't rely on implicit fallthrough in `switch` statements](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-break) in the C++ Core Guidelines.
+For more information, see [ES.78: Don't rely on implicit fallthrough in `switch` statements](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es78-dont-rely-on-implicit-fallthrough-in-switch-statements) in the C++ Core Guidelines.
 
 ## Example
 
@@ -87,4 +87,4 @@ void foo(int a)
 
 ## See also
 
-[ES.78: Don't rely on implicit fallthrough in `switch` statements](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Res-break)
+[ES.78: Don't rely on implicit fallthrough in `switch` statements](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es78-dont-rely-on-implicit-fallthrough-in-switch-statements)
diff --git a/docs/code-quality/c26820.md b/docs/code-quality/c26820.md
@@ -9,7 +9,7 @@ helpviewer_keywords: ["C26820"]
 
 > This is a potentially expensive copy operation. Consider using a reference unless a copy is required (p.9)
 
-For more information, see [P.9: Don't waste time or space](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#Rp-waste) in the C++ Core Guidelines.
+For more information, see [P.9: Don't waste time or space](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#p9-dont-waste-time-or-space) in the C++ Core Guidelines.
 
 This check covers nonobvious and easy-to-miss behavior when assigning a reference to a variable marked **`auto`**. The type of the **`auto`** variable is resolved to a value rather than a reference, and an implicit copy is made.
 
diff --git a/docs/code-quality/c26826.md b/docs/code-quality/c26826.md
@@ -9,7 +9,7 @@ helpviewer_keywords: ["C26826"]
 
 > Don't use C-style variable arguments (f.55).
 
-For more information, see [F.55: Don't use `va_arg` arguments](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#F-varargs) in the C++ Core Guidelines.
+For more information, see [F.55: Don't use `va_arg` arguments](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#f55-dont-use-va_arg-arguments) in the C++ Core Guidelines.
 
 ## Remarks
 
diff --git a/docs/ide/include-cleanup-overview.md b/docs/ide/include-cleanup-overview.md
@@ -56,7 +56,7 @@ int main()
 
 The issue is that `myProgram.cpp` uses `std::string` and `std::cout`, but doesn't directly include the headers that define them. This code happens to compile because `myHeader.h` includes those headers. This code is brittle because if `myHeader.h` ever stopped including either one, `myProgram.cpp` wouldn't compile anymore.
 
-Per the C++ guidelines, it's better to explicitly include headers for all of your dependencies so that your code isn't subject to brittleness caused by changes to header files. For more information, see [C++ Core Guidelines SF.10](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#sf10-avoid-dependencies-on-implicitly-included-names).
+Per the C++ guidelines, it's better to explicitly include headers for all of your dependencies so that your code isn't subject to brittleness caused by changes to header files. For more information, see [SF.10: Avoid dependencies on implicitly `#include`d names](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#sf10-avoid-dependencies-on-implicitly-included-names) in the C++ Core Guidelines.
 
 Include Cleanup analyzes your code to identify unused and indirectly included headers. It provides feedback based on the settings described in [Config the C++ #include tool in Visual Studio](include-cleanup-config.md). Feedback can be in the form of error list warnings, suggestions, etc. For more details on the feedback provided by Include Cleanup, refer [Include Cleanup messages](include-cleanup-messages.md).
 
diff --git a/docs/ide/lnt-make-member-function-const.md b/docs/ide/lnt-make-member-function-const.md
@@ -8,7 +8,7 @@ monikerRange: ">=msvc-170"
 ---
 # `lnt-make-member-function-const`
 
-When a member function doesn't modify the object's state, annotate it with the `const` keyword. This guidance comes from the [C++ Core Guideline Con.2](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#con2-by-default-make-member-functions-const).
+When a member function doesn't modify the object's state, annotate it with the `const` keyword. This guidance comes from [Con.2: By default, make member functions `const`](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#con2-by-default-make-member-functions-const) in the C++ Core Guidelines.
 
 ## Example
 
diff --git a/docs/ide/lnt-uninitialized-local.md b/docs/ide/lnt-uninitialized-local.md
@@ -10,7 +10,7 @@ monikerRange: ">=msvc-160"
 
 Local variables should be initialized when they're declared.
 
-This guidance comes from the [C++ Core Guideline ES.20](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es20-always-initialize-an-object).
+This guidance comes from [ES.20: Always initialize an object](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es20-always-initialize-an-object) in the C++ Core Guidelines.
 
 The `lnt-uninitialized-local` check is controlled by the **Uninitialized Local Variable** setting in the C/C++ Code Style options. For information on how to change this setting, see [Configure the linter](cpp-linter-overview.md#configure-the-linter).
 
@@ -55,5 +55,5 @@ Using "Almost Always Auto" for declarations requires initialization at declarati
 ## See also
 
 [IntelliSense code linter for C++ overview](cpp-linter-overview.md)\
-[C++ Core Guidelines](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es20-always-initialize-an-object)\
+[ES.20: Always initialize an object](https://isocpp.github.io/CppCoreGuidelines/CppCoreGuidelines#es20-always-initialize-an-object)\
 [Almost Always Auto - Herb Sutter](https://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/)
diff --git a/docs/overview/cpp-conformance-improvements.md b/docs/overview/cpp-conformance-improvements.md
