Line edits2

Author: lootle1

learn-pr/github/code-scanning-with-github-codeql/includes/2-what-is-codeql.md

@@ -38,7 +38,7 @@ There are two built-in query suites for CodeQL:
 * `default`: These are the queries run by default in CodeQL code scanning on GitHub, available with the default setup of code scanning. The queries in this query suite are highly precise and return few false positive code scanning results. Relative to the `security-extended` query suite, the default suite returns fewer low-confidence code scanning results.
 * `security-extended`: This suite contains all of the queries from the `default` suite, plus extra security queries with slightly lower precision and severity. It's available with the default setup of code scanning and is listed as the "Extended" option in the query suites dropdown. Relative to the `default` query suite, this suite may return a greater number of false positive code scanning results.
 
-The default setup of code scanning will use the `default` query suite. This can be changed by selecting the overflow icon to view the CodeQL configuration, and then selecting to the edit button. Under "Scan settings," you may choose one of the above two options as the query suite.
+The default setup of code scanning will use the `default` query suite. This can be changed by selecting the overflow icon to view the CodeQL configuration, and then selecting to the edit button. Under "Scan settings," you may choose one of the two options outlined as the query suite.
 
 ## CodeQL packs
 
@@ -47,8 +47,8 @@ CodedQL packs are used to organize the files used in CodeQL analysis so you can
 There are three types of CodeQL packs: query packs, library packs, and model packs.
 
 * Query packs are designed to be run. When a query pack is published, the bundle includes all the transitive dependencies and pre-compiled representations of each query, in addition to the query sources. This ensures consistent and efficient execution of the queries in the pack.
-* Library packs are designed to be used by query packs (or other library packs) and do not contain queries themselves. The libraries are not compiled separately.
-* Model packs can be used to expand code scanning analysis to include dependencies that are not supported by default. Model packs are currently in beta and subject to change. During the beta, model packs are available for Java analysis at the repository level. For more information about creating your own model packs, see "Creating a CodeQL model pack."
+* Library packs are designed to be used by query packs (or other library packs) and don't contain queries themselves. The libraries aren't compiled separately.
+* Model packs can be used to expand code scanning analysis to include dependencies that aren't supported by default. Model packs are currently in beta and subject to change. During the beta, model packs are available for Java analysis at the repository level. For more information about creating your own model packs, see "Creating a CodeQL model pack."
 
 ### CodeQL pack structure
 

learn-pr/github/code-scanning-with-github-codeql/includes/3-how-does-codeql-analyze-code.md

@@ -16,7 +16,7 @@ For compiled languages, extraction works by monitoring the normal build process.
 
 For interpreted languages, the extractor runs directly on the source code, resolving dependencies to give an accurate representation of the codebase.
 
-There is one extractor for each language supported by CodeQL to ensure that the extraction process is as accurate as possible. For multi-language codebases, databases are generated one language at a time.
+There's one extractor for each language supported by CodeQL to ensure that the extraction process is as accurate as possible. For multi-language codebases, databases are generated one language at a time.
 
 After extraction, all the data required for analysis (relational data, copied source files, and a language-specific database schema that specifies the mutual relations in the data) is imported into a single directory, known as a CodeQL database.
 
@@ -32,6 +32,6 @@ The final step converts results produced during query execution into a form that
 
 :::image type="content" source="../media/codeql-query-results.png" alt-text="Screenshot of CodeQL query results.":::
 
-Queries contain metadata properties that indicate how the results should be interpreted. For instance, some queries display a simple message at a single location in the code. Others display a series of locations that represent steps along a data-flow or control-flow path, along with a message explaining the significance of the result. Queries that don't have metadata are not interpreted; their results are output as a table and not displayed in the source code.
+Queries contain metadata properties that indicate how the results should be interpreted. For instance, some queries display a simple message at a single location in the code. Others display a series of locations that represent steps along a data-flow or control-flow path, along with a message explaining the significance of the result. Queries that don't have metadata aren't interpreted; their results are output as a table and not displayed in the source code.
 
 Following interpretation, results are output for code review and triaging. In CodeQL for Visual Studio Code, interpreted query results are automatically displayed in the source code. You can output results generated by the CodeQL CLI into a number of different formats for use with different tools.

learn-pr/github/code-scanning-with-github-codeql/includes/4-what-is-ql.md

@@ -17,7 +17,7 @@ The syntax of QL is similar to SQL. However, the semantics of QL are based on Da
 1. Find a descendant of the given person; that is, a child or a descendant of a child.
 2. Count the number of descendants found using the previous step.
 
-When you write this process in QL, it closely resembles the above structure. Notice that the example used recursion to find all descendants of the given person, and an aggregate to count the number of descendants. Translating these steps into the final query without adding any procedural details is possible due to the declarative nature of the language. The QL code would look something like this:
+When you write this process in QL, it closely resembles this described structure. Notice that the example used recursion to find all descendants of the given person, and an aggregate to count the number of descendants. Translating these steps into the final query without adding any procedural details is possible due to the declarative nature of the language. The QL code would look something like this:
 
 ```ql
 Person getADescendant(Person p) {
@@ -38,7 +38,7 @@ Object orientation is an important feature of QL. The benefits of object orienta
 
 Here are a few prominent conceptual and functional differences between general purpose programming languages and QL:
 
-* QL does not have any imperative features such as assignments to variables or file system operations.
+* QL doesn't have any imperative features such as assignments to variables or file system operations.
 * QL operates on sets of tuples, and a query can be viewed as a complex sequence of set operations that defines the result of the query.
 * QL's set-based semantics makes it very natural to process collections of values without having to worry about efficiently storing, indexing, and traversing them.
 

learn-pr/github/code-scanning-with-github-codeql/includes/6-customize-your-scanning-workflow-with-codeql.md

@@ -29,7 +29,7 @@ We don't recommend referencing query suites directly from the `github/codeql` re
 
 To add one or more CodeQL query packs (beta), add a `with: packs:` entry within the `uses: github/codeql-action/init@v1` section of the workflow. Within packs, you can specify one or more packages to use and, optionally, which version to download. Where you don't specify a version, the latest version is downloaded. If you want to use packages that aren't publicly available, you need to set the `GITHUB_TOKEN` environment variable to a secret that has access to the packages.
 
-In the following example, scope is the organization or personal account that published the package. When the workflow runs, the three CodeQL query packs download from GitHub and the default queries or query suite for each pack run. In the below example, each of the packs in the list will download based on their specifications:
+In the following example, scope is the organization or personal account that published the package. When the workflow runs, the three CodeQL query packs download from GitHub and the default queries or query suite for each pack run. In the following example, each of the packs in the list will download based on their specifications:
 * The latest version of `pack1` is downloaded, and all default queries are run.
 * Version 1.2.3 of `pack2` is downloaded, and all default queries are run.
 * The latest version of `pack3` that is compatible with version 3.2.1 is downloaded, and all queries are run.

learn-pr/github/code-scanning-with-github-codeql/includes/8-customize-your-scanning-workflow-with-codeql-2.md

@@ -110,10 +110,10 @@ If you only want to run custom queries, you can disable the default security que
 You can add `exclude` and `include` filters to your custom configuration file, to specify the queries you want to exclude or include in the analysis, such as:
 
 * Specific queries from the default suites (`security`, `security-extended` and `security-and-quality`).
-* Specific queries whose results do not interest you.
+* Specific queries whose results don't interest you.
 * All the queries that generate warnings and recommendations.
 
-You can use `exclude` filters similar to those in the configuration the following file to exclude queries that you want to remove from the default analysis. In the example of configuration file below, both the `js/redundant-assignment` and the `js/useless-assignment-to-local` queries are excluded from analysis.
+You can use `exclude` filters similar to those in the configuration the following file to exclude queries that you want to remove from the default analysis. In the example of a configuration file that follows, both the `js/redundant-assignment` and the `js/useless-assignment-to-local` queries are excluded from analysis.
 
 ```yml
 query-filters:
@@ -143,9 +143,9 @@ paths-ignore:
 ```
 
 > [!NOTE]
-> * The `paths` and `paths-ignore` keywords, used in the context of the code scanning configuration file, should not be confused with the same keywords when used for `on.<push|pull_request>.paths` in a workflow. When they're used to modify `on.<push|pull_request>` in a workflow, they determine whether the actions will be run when someone modifies code in the specified directories.
+> * The `paths` and `paths-ignore` keywords, used in the context of the code scanning configuration file, shouldn't be confused with the same keywords when used for `on.<push|pull_request>.paths` in a workflow. When they're used to modify `on.<push|pull_request>` in a workflow, they determine whether the actions will be run when someone modifies code in the specified directories.
 > * The filter pattern characters `?`, `+`, `[`, `]`, and `!` aren't supported and will be matched literally.
-> * `**` characters can only be at the start or end of a line, or surrounded by slashes, and you can't mix `**` and other characters. For example: `foo/**`, `**/foo`, and `foo/**/bar` are all allowed syntax, but `**foo` isn't. However ,you can use single stars along with other characters, as shown in the example. You'll need to quote anything that contains a `*` character.
+> * `**` characters can only be at the start or end of a line, or surrounded by slashes, and you can't mix `**` and other characters. For example: `foo/**`, `**/foo`, and `foo/**/bar` are all allowed syntax, but `**foo` isn't. However, you can use single stars along with other characters, as shown in the example. You'll need to quote anything that contains a `*` character.
 
 For compiled languages, if you want to limit code scanning to specific directories in your project, you must specify appropriate build steps in the workflow. The commands you need to use to exclude a directory from the build will depend on your build system.
 

learn-pr/github/code-scanning-with-github-codeql/includes/9-use-codeql-cli.md

@@ -48,9 +48,9 @@ The full list of parameters for the `database create` command is shown in the fo
 |---|---|
 |`<database>` | Specify the name and location of a directory to create for the CodeQL database. The command will fail if you try to overwrite an existing directory. If you also specify `--db-cluster`, this is the parent directory, and a subdirectory is created for each language analyzed. |
 | `--language` | Specify the identifier for the language to create a database for one of `cpp`, `csharp`, `go`, `java`, `javascript`, `python`, and `ruby` (use JavaScript to analyze TypeScript code). When used with `--db-cluster`, the option accepts a comma-separated list, or can be specified more than once. |
-| `--command` | Recommended. Use to specify the build command or script that invokes the build process for the codebase. Commands are run from the current folder or, where it is defined, from `--source-root`. Not needed for Python and JavaScript/TypeScript analysis. |
+| `--command` | Recommended. Use to specify the build command or script that invokes the build process for the codebase. Commands are run from the current folder or, where it's defined, from `--source-root`. Not needed for Python and JavaScript/TypeScript analysis. |
 | `--db-cluster` | Optional. Use in multi-language codebases to generate one database for each language specified by `--language`.|
-| `--no-run-unnecessary-builds`	| Recommended. Use to suppress the build command for languages where the CodeQL CLI does not need to monitor the build (for example, Python and JavaScript/TypeScript).|
+| `--no-run-unnecessary-builds`	| Recommended. Use to suppress the build command for languages where the CodeQL CLI doesn't need to monitor the build (for example, Python and JavaScript/TypeScript).|
 | `--source-root` | Optional. Use if you run the CLI outside the checkout root of the repository. By default, the database create command assumes that the current directory is the root directory for the source files; use this option to specify a different location.|
 
 ### Single language example
@@ -156,9 +156,9 @@ $ codeql database analyze /codeql-dbs/example-repo  \
 
 ## Upload results to GitHub
 
-SARIF upload supports a maximum of 25,000 results per upload. However, only the top 5,000 results will be displayed, prioritized by severity. If a tool generates too many results, you should update the configuration to focus on results for the most important rules or queries.
+SARIF upload supports a maximum of 25,000 results per upload. However, only the top 5,000 results are displayed, prioritized by severity. If a tool generates too many results, you should update the configuration to focus on results for the most important rules or queries.
 
-For each upload, SARIF upload supports a maximum size of 10 MB for the gzip-compressed SARIF file. Any uploads over this limit will be rejected. If your SARIF file is too large because it contains too many results, you should update the configuration to focus on results for the most important rules or queries. For more information on limitations and validating SARIF files see the documentation<sup>[6]</sup>.
+For each upload, SARIF upload supports a maximum size of 10 MB for the gzip-compressed SARIF file. Any uploads over this limit will be rejected. If your SARIF file is too large because it contains too many results, you should update the configuration to focus on results for the most important rules or queries. For more information on limitations and validating SARIF files, see the documentation<sup>[6]</sup>.
 
 Before you can upload results to GitHub, you must determine the best way to pass the GitHub App or personal access token you created earlier to the CodeQL CLI. We recommend that you review your CI system's guidance on the secure use of a secret store. The CodeQL CLI supports:
 
@@ -182,7 +182,7 @@ codeql github upload-results \
     --sarif=<file> 
 ```
 
-The full list of parameters for the `github upload-results` command is shown in the table below.
+The full list of parameters for the `github upload-results` command is shown in the table as follows.
 
 |Option	|Required Usage|
 |---|---|

learn-pr/github/code-scanning-with-github-codeql/knowledge-check.yml

@@ -40,10 +40,10 @@ quiz:
     choices:
     - content: "Scheduled events are more difficult to configure than triggered events."
       isCorrect: false
-      explanation: "Incorrect. Scheduled events are not more difficult to configure than triggered events. Both can be configured easily. "
+      explanation: "Incorrect. Scheduled events aren't more difficult to configure than triggered events. Both can be configured easily. "
     - content: "Scheduled events run based on a specified schedule and triggered events run on code events such a push. "
       isCorrect: true
-      explanation: "Correct. Scheduled events are specified by the developer and triggered events are set by default but can also be configured by the developer."
+      explanation: "Correct. The developer specifies scheduled events and triggered events are set by default but can also be developer configured."
     - content: "Triggered events run less frequently than scheduled events."
       isCorrect: false
       explanation: "Incorrect. The frequency of both triggered events and scheduled events varies depending on how often pushes and pull requests occur, as well as how the developer may have configured the frequency."