Repo sync for protected branch

docs/code-quality/build-reliable-secure-programs.md

@@ -1,7 +1,7 @@
 ---
 description: "Learn more about: Building reliable and secure C++ programs by applying NISTIR 8397 guidelines."
 title: Build reliable and secure C++ programs
-ms.date: 09/20/2023
+ms.date: 09/28/2023
 ms.topic: "conceptual"
 ---
 
@@ -182,11 +182,11 @@ Remove the now-invalidated secrets from your source code, and replace them with
 
 **Azure DevOps (AzDO)**
 
-AzDO users can scan their code through Microsoft Defender for DevOps for known types of secrets. Defender for DevOps, a service available in Defender for Cloud, empowers security teams to manage DevOps security across multi-pipeline environments. Defender for DevOps is current in preview, available for free trial. Defender for DevOps provides the scanning service through GitHub Advanced Security for Azure DevOps (GHAS for AzDO).  For more information on how to detect hardcoded secrets in code in Azure DevOps, see "Detect exposed secrets in code" in the following list of links:
+AzDO users can scan their code through GitHub Advanced Security for Azure DevOps (GHAzDO). GHAzDO also allows users to prevent secret exposures by enabling Push Protection on their repositories, catching potential exposures before they're ever leaked. For more information on how to detect hardcoded secrets in code in Azure DevOps, see *Secret Scanning for Github Advanced Security for Azure DevOps* in each of the following links:
 
+- [GitHub advanced security for Azure DevOps](https://azure.microsoft.com/products/devops/github-advanced-security)
+- [Secret Scanning for GitHub Advanced Security for Azure DevOps](/azure/devops/repos/security/github-advanced-security-secret-scanning)
 - [Microsoft Defender for DevOps Preview](https://www.microsoft.com/security/business/cloud-security/microsoft-defender-devops)
-- [GitHub advanced security for Azure DevOps (GHAS for AzDO) | GitHub](https://partner.github.com/2022/10/12/azure-devops-article.html)
-- [Detect exposed secrets in code](/azure/defender-for-cloud/detect-exposed-secrets)
 
 **In GitHub**
 
@@ -201,7 +201,7 @@ GitHub provides known patterns of secrets for partners and users that can be con
 - [About secret scanning in GitHub](https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/about-secret-scanning)
 
 > [!NOTE]
-> During the Microsoft Defender for DevOps preview period, GitHub Advanced Security for Azure DevOps (GHAS for AzDO) is also providing a free trial of secret scanning. GitHub Advanced Security for Azure DevOps brings the same secret scanning, dependency scanning and CodeQL code scanning solutions already available for GitHub users and natively integrates them into Azure DevOps to protect your Azure Repos and Pipelines.
+> GitHub Advanced Security for Azure DevOps brings the same secret scanning, dependency scanning and CodeQL code scanning solutions already available for GitHub users and natively integrates them into Azure DevOps to protect your Azure Repos and Pipelines.
 
 **Additional resources**
 
@@ -383,7 +383,7 @@ When fuzzing reports a failure, it always naturally provides a reproducible test
 
 When using both sanitizers such as [Address Sanitizer (ASan)](../sanitizers/asan.md) and fuzzing:
 - First run your normal tests with sanitizers enabled to see if there are issues, then once the code is sanitizer-clean start fuzzing.
-- For C or C++, there are compilers that automate injection of runtime assertions and meta-data that enable ASan. When compiled for ASan, the resulting binaries link with a runtime library that can precisely diagnose [15+ categories of memory safety errors](../sanitizers/asan.md#error-types) with zero false positives. For C or C++ when you have source, use [LibFuzzer](https://www.llvm.org/docs/LibFuzzer.html) which requires ASan to be enabled first.
+- For C or C++, there are compilers that automate injection of runtime assertions and meta-data that enable ASan. When compiled for ASan, the resulting binaries link with a runtime library that can precisely diagnose [15+ categories of memory safety errors](../sanitizers/asan.md#error-types) with zero false positives. For C or C++ when you have source, use [LibFuzzer](https://www.llvm.org/docs/LibFuzzer.html), which requires ASan to be enabled first.
 - For libraries written in Java, C#, Python, Rust, and so on, use the [AFL++ framework](https://aflplus.plus/).
 
 **Key qualities**

docs/ide/lnt-arithmetic-overflow.md

@@ -17,6 +17,8 @@ The `lnt-arithmetic-overflow` check is controlled by the **Arithmetic Overflow**
 ## Examples
 
 ```cpp
+#include <cstdint>
+
 void overflow(int a, int b) {
     int64_t mul = a * b;      // Flagged: 32-bit operation may overflow.
     int64_t shift = a << 34;  // Flagged: Shift would overflow.

docs/ide/lnt-make-member-function-const.md

@@ -0,0 +1,78 @@
+---
+title: lnt-make-member-function-const
+description: "Reference for Visual Studio C++ IntelliSense Linter check lnt-make-member-function-const."
+ms.date: 09/28/2023
+f1_keywords: ["lnt-make-member-function-const"]
+helpviewer_keywords: ["lnt-make-member-function-const"]
+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).
+
+## Example
+
+The linter flags the following code twice because `getValue()` and `getRadius()` don't modify the object's state:
+
+```cpp
+class MyClass
+{ 
+public: 
+
+  int getValue() { return value; }  // Flagged: ‘getValue’ doesn't modify the object's state. 
+  void setValue(int newValue) { value = newValue; }  // OK: ‘setValue’ modifies the object's state.   
+
+private: 
+
+  int value = 42; 
+}; 
+
+double getRadius()
+{   // Flagged: ‘getRadius’ doesn't modify the object's state. 
+    return radius; 
+} 
+```
+
+## How to fix the issue
+
+Mark member functions `const` when they don't modify the object's state. This lets readers of the code and the compiler know that the function is safe to call on a `const` object.
+
+In the following example, `const` has been added to `getValue()` and `getRadius()`:
+
+```cpp
+class MyClass
+{ 
+public: 
+
+  int getValue() const { return value; }  // Added const 
+  void setValue(int newValue) { value = newValue; }  // OK: ‘setValue’ modifies the object's state.   
+
+private: 
+
+  int value = 42; 
+
+}; 
+
+double getRadius() const // added const
+{   // ‘getRadius’ doesn't modify the object's state. 
+    return radius; 
+}  
+```
+
+The editor can make this change for you. Place the cursor on the flagged symbol and choose **Show potential fixes** and then **Make member const**:
+
+:::image type="complex" source="media/lnt-make-member-function-const.png" alt-text="Screenshot of the editor suggesting to make member const." :::
+The cursor is on the line int getValue() and **Show potential fixes** appeared and was chosen. Now **Make member const** is visible and it shows the get value function with const added to it. You can now choose **Make member const** to make the change.
+:::image-end:::
+
+Make this change for all flagged member functions.
+
+## Remarks
+
+Introduced in Visual Studio 2022 17.8, this check focuses on `const` usage for member functions in C++ code. The C++ Core Guidelines recommends marking member functions as `const` when they don't modify the object's state.
+
+The current implementation of this check allows you to add `const` to member functions after their declaration. It's a good practice to declare member functions as `const` from the beginning if they don't modify the object's state.
+
+## See also
+
+[IntelliSense code linter for C++ overview](cpp-linter-overview.md)

docs/ide/lnt-naming-convention.md

@@ -0,0 +1,59 @@
+---
+title: lnt-naming-convention
+description: "Reference for Visual Studio C++ IntelliSense Linter check lnt-naming-convention."
+ms.date: 09/28/2023
+f1_keywords: ["lnt-naming-convention"]
+helpviewer_keywords: ["lnt-naming-convention"]
+monikerRange: ">=msvc-170"
+---
+# `lnt-naming-convention`
+
+Ensure that the naming convention for symbols aligns with your coding style, as specified in the project's `.editorconfig` file.
+
+To enable this feature, add an `.editorconfig` file in the same directory as your project file. The `.editorconfig` specifies the naming conventions for symbols in your project. As an example, the naming conventions for Unreal Engine projects are specified in an `.editorconfig` on [GitHub](https://raw.githubusercontent.com/microsoft/vc-ue-extensions/main/Source/.editorconfig).
+
+Once you have the `.editorconfig` file in your project, turn on the `lnt-naming-convention` check with the **Naming Convention** setting in the C/C++ Code Style options. For information about how to change this setting, see [Configure the linter](cpp-linter-overview.md#configure-the-linter).
+
+## Example
+
+Suppose that you have an `.editorconfig` file that contains:
+
+```
+cpp_naming_style.boolean_style.capitalization = pascal_case
+cpp_naming_style.boolean_style.required_prefix = b
+```
+
+The linter flags the following code because it isn't prefixed with 'b' and because it isn't Pascal case, as specified in the `.editorconfig` file:
+
+```cpp
+void example()
+{
+    bool myFlag = true; // flagged because it doesn't follow the naming convention specified in the .editorconfig
+}
+```
+
+## How to fix the issue
+
+Change the naming to match the style specified in the `.editorconfig`:
+
+```cpp
+void example()
+{ 
+    bool bMyFlag = true; // fixed to follow the code style specified in the .editorconfig
+} 
+```
+
+The editor can make the change for you. Place the cursor on the flagged symbol. Choose **Show potential fixes** and then **Apply naming convention**:
+
+:::image type="complex" source="media/lnt-apply-naming-convention.png" alt-text="Screenshot of the IDE suggesting applying naming convention.":::
+The code editor shows bool myFlag = true. With the cursor on that line of code, **Show potential fixes** appeared and was chosen. Now **Apply naming convention** is visible and it shows bool my Flag = true in red and the suggested change, bool b My Flag, in green. You can now choose **Apply naming convention** to change the flagged code to bool b My Flag = true.
+:::image-end:::
+
+## Remarks
+
+Introduced in Visual Studio 2022 17.7, the `lnt-naming-convention` linter check ensures that naming conventions align with those specified in the `.editorconfig` file. You can apply this check to any project that has an `.editorconfig` file. You can also customize your `.editorconfig` file to suit your project's coding style.
+
+## See also
+
+[Create portable, custom editor settings with EditorConfig](/visualstudio/ide/create-portable-custom-editor-options)\
+[IntelliSense code linter for C++ overview](cpp-linter-overview.md)

docs/ide/toc.yml

@@ -30,6 +30,10 @@ items:
         href: ../ide/lnt-integer-float-division.md
       - name: lnt-logical-bitwise-mismatch
         href: ../ide/lnt-logical-bitwise-mismatch.md
+      - name: lnt-make-member-function-const
+        href: ../ide/lnt-make-member-function-const.md
+      - name: lnt-naming-convention
+        href: ../ide/lnt-naming-convention.md
       - name: lnt-uninitialized-local
         href: ../ide/lnt-uninitialized-local.md
     - name: Change signature