You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: docs/code-quality/build-reliable-secure-programs.md
+6-6Lines changed: 6 additions & 6 deletions
Original file line number
Diff line number
Diff line change
@@ -1,7 +1,7 @@
1
1
---
2
2
description: "Learn more about: Building reliable and secure C++ programs by applying NISTIR 8397 guidelines."
3
3
title: Build reliable and secure C++ programs
4
-
ms.date: 09/20/2023
4
+
ms.date: 09/28/2023
5
5
ms.topic: "conceptual"
6
6
---
7
7
@@ -182,11 +182,11 @@ Remove the now-invalidated secrets from your source code, and replace them with
182
182
183
183
**Azure DevOps (AzDO)**
184
184
185
-
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:
185
+
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:
186
186
187
+
-[GitHub advanced security for Azure DevOps](https://azure.microsoft.com/products/devops/github-advanced-security)
188
+
-[Secret Scanning for GitHub Advanced Security for Azure DevOps](/azure/devops/repos/security/github-advanced-security-secret-scanning)
187
189
-[Microsoft Defender for DevOps Preview](https://www.microsoft.com/security/business/cloud-security/microsoft-defender-devops)
188
-
-[GitHub advanced security for Azure DevOps (GHAS for AzDO) | GitHub](https://partner.github.com/2022/10/12/azure-devops-article.html)
189
-
-[Detect exposed secrets in code](/azure/defender-for-cloud/detect-exposed-secrets)
190
190
191
191
**In GitHub**
192
192
@@ -201,7 +201,7 @@ GitHub provides known patterns of secrets for partners and users that can be con
201
201
-[About secret scanning in GitHub](https://docs.github.com/en/enterprise-cloud@latest/code-security/secret-scanning/about-secret-scanning)
202
202
203
203
> [!NOTE]
204
-
> 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.
204
+
> 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.
205
205
206
206
**Additional resources**
207
207
@@ -383,7 +383,7 @@ When fuzzing reports a failure, it always naturally provides a reproducible test
383
383
384
384
When using both sanitizers such as [Address Sanitizer (ASan)](../sanitizers/asan.md) and fuzzing:
385
385
- First run your normal tests with sanitizers enabled to see if there are issues, then once the code is sanitizer-clean start fuzzing.
386
-
- 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.
386
+
- 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.
387
387
- For libraries written in Java, C#, Python, Rust, and so on, use the [AFL++ framework](https://aflplus.plus/).
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).
12
+
13
+
## Example
14
+
15
+
The linter flags the following code twice because `getValue()` and `getRadius()` don't modify the object's state:
16
+
17
+
```cpp
18
+
classMyClass
19
+
{
20
+
public:
21
+
22
+
int getValue() { return value; } // Flagged: ‘getValue’ doesn't modify the object's state.
23
+
void setValue(int newValue) { value = newValue; } // OK: ‘setValue’ modifies the object's state.
24
+
25
+
private:
26
+
27
+
int value = 42;
28
+
};
29
+
30
+
doublegetRadius()
31
+
{ // Flagged: ‘getRadius’ doesn't modify the object's state.
32
+
return radius;
33
+
}
34
+
```
35
+
36
+
## How to fix the issue
37
+
38
+
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.
39
+
40
+
In the following example, `const` has been added to `getValue()` and `getRadius()`:
41
+
42
+
```cpp
43
+
classMyClass
44
+
{
45
+
public:
46
+
47
+
int getValue() const { return value; } // Added const
48
+
void setValue(int newValue) { value = newValue; } // OK: ‘setValue’ modifies the object's state.
49
+
50
+
private:
51
+
52
+
int value = 42;
53
+
54
+
};
55
+
56
+
doublegetRadius() const// added const
57
+
{ // ‘getRadius’ doesn't modify the object's state.
58
+
return radius;
59
+
}
60
+
```
61
+
62
+
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**:
63
+
64
+
:::image type="complex" source="media/lnt-make-member-function-const.png" alt-text="Screenshot of the editor suggesting to make member const." :::
65
+
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.
66
+
:::image-end:::
67
+
68
+
Make this change for all flagged member functions.
69
+
70
+
## Remarks
71
+
72
+
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.
73
+
74
+
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.
75
+
76
+
## See also
77
+
78
+
[IntelliSense code linter for C++ overview](cpp-linter-overview.md)
description: "Reference for Visual Studio C++ IntelliSense Linter check lnt-naming-convention."
4
+
ms.date: 09/28/2023
5
+
f1_keywords: ["lnt-naming-convention"]
6
+
helpviewer_keywords: ["lnt-naming-convention"]
7
+
monikerRange: ">=msvc-170"
8
+
---
9
+
# `lnt-naming-convention`
10
+
11
+
Ensure that the naming convention for symbols aligns with your coding style, as specified in the project's `.editorconfig` file.
12
+
13
+
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).
14
+
15
+
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).
16
+
17
+
## Example
18
+
19
+
Suppose that you have an `.editorconfig` file that contains:
cpp_naming_style.boolean_style.required_prefix = b
24
+
```
25
+
26
+
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:
27
+
28
+
```cpp
29
+
voidexample()
30
+
{
31
+
bool myFlag = true; // flagged because it doesn't follow the naming convention specified in the .editorconfig
32
+
}
33
+
```
34
+
35
+
## How to fix the issue
36
+
37
+
Change the naming to match the style specified in the `.editorconfig`:
38
+
39
+
```cpp
40
+
voidexample()
41
+
{
42
+
bool bMyFlag = true; // fixed to follow the code style specified in the .editorconfig
43
+
}
44
+
```
45
+
46
+
The editor can make the change for you. Place the cursor on the flagged symbol. Choose **Show potential fixes** and then **Apply naming convention**:
47
+
48
+
:::image type="complex" source="media/lnt-apply-naming-convention.png" alt-text="Screenshot of the IDE suggesting applying naming convention.":::
49
+
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.
50
+
:::image-end:::
51
+
52
+
## Remarks
53
+
54
+
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.
55
+
56
+
## See also
57
+
58
+
[Create portable, custom editor settings with EditorConfig](/visualstudio/ide/create-portable-custom-editor-options)\
59
+
[IntelliSense code linter for C++ overview](cpp-linter-overview.md)
0 commit comments