diff --git a/tools/cds-lint/rules/assoc2many-ambiguous-key.md b/tools/cds-lint/rules/assoc2many-ambiguous-key.md index d53bd2abf..c2a88772a 100644 --- a/tools/cds-lint/rules/assoc2many-ambiguous-key.md +++ b/tools/cds-lint/rules/assoc2many-ambiguous-key.md @@ -14,7 +14,7 @@ status: released ## Rule Details -In general an [association/composition to/of `MANY`](../../../cds/cdl#to-many-associations) that targets an entity without `ON` condition is not allowed (as it is an `n:1` relationship). Here, one should always specify an `ON` condition following the canonical expression pattern `. = $self`. The backlink can be any managed to-one association on the many side pointing back to the one side. +An [association/composition to/of `MANY`](../../../cds/cdl#to-many-associations) that targets an entity without an `ON` condition is not allowed because it is an `n:1` relationship. Always specify an `ON` condition following the canonical expression pattern `. = $self`. The backlink can be any managed to-one association on the many side pointing back to the one side. ## Examples @@ -34,7 +34,7 @@ In the following example, we define a unique association from `Authors` to `Book #### ❌   Incorrect example -If we extend this example by creating a view `AuthorView` with a key `ID` and the element `bookIDs` without an `ON` condition, the rule is triggered since the key is no longer unique and `bookIDs` leads to multiple entries: +If you extend this example by creating a view `AuthorView` with a key `ID` and the element `bookIDs` without an `ON` condition, the rule is triggered because the key is no longer unique and `bookIDs` leads to multiple entries: ::: code-group <<< ../examples/assoc2many-ambiguous-key/incorrect/db/schema.cds#snippet{cds:line-numbers} [db/schema.cds] diff --git a/tools/cds-lint/rules/auth-no-empty-restrictions.md b/tools/cds-lint/rules/auth-no-empty-restrictions.md index baabfb236..773e676e2 100644 --- a/tools/cds-lint/rules/auth-no-empty-restrictions.md +++ b/tools/cds-lint/rules/auth-no-empty-restrictions.md @@ -14,7 +14,7 @@ status: released ## Rule Details -The [`@requires` annotation](../../../guides/security/authorization#requires) is a convenience shortcut for `@restrict`. You can use it to control which rule a user needs to have in order to access a given resource. Leaving this field empty is dangerous as it leads to unrestricted access to that service which is a security risk. +The [`@requires` annotation](../../../guides/security/authorization#requires) is a convenience shortcut for `@restrict`. You can use it to control which rule a user needs to access a given resource. Leaving this field empty is dangerous because it leads to unrestricted access to that service, which is a security risk. ## Examples @@ -34,8 +34,7 @@ In the following example, the `AdminService` is correctly setup with `@requires` #### ❌   Incorrect example -If we were to replace the `admin` role by an empty string or provide an empty role array as shown in the next example, -we now have unrestricted access to that service, which the rule makes us aware of: +If you replace the `admin` role with an empty string or provide an empty role array as shown in the next example, you now have unrestricted access to that service, which the rule makes you aware of: ::: code-group <<< ../examples/auth-no-empty-restrictions/incorrect/srv/admin-service.cds#snippet{cds:line-numbers} [srv/admin-service.cds] diff --git a/tools/cds-lint/rules/auth-restrict-grant-service.md b/tools/cds-lint/rules/auth-restrict-grant-service.md index 1c4ef4358..95446469d 100644 --- a/tools/cds-lint/rules/auth-restrict-grant-service.md +++ b/tools/cds-lint/rules/auth-restrict-grant-service.md @@ -14,9 +14,9 @@ status: released ## Rule Details -Restrictions can be defined on different types of CDS resources, but there are some limitations with regard to supported privileges (see [limitations](../../../guides/security/authorization#supported-combinations-with-cds-resources)). +Restrictions can be defined on different types of CDS resources, but there are some limitations regarding supported privileges (see [limitations](../../../guides/security/authorization#supported-combinations-with-cds-resources)). -Unsupported privilege properties are ignored by the runtime. Especially, for bound or unbound actions, the `grant` property is implicitly removed (assuming `grant: '*'` instead). The same is true for functions. This rule ensures that `@restrict.grant` on service level and for bound/unbound actions and functions is limited to `grant: '*'`. +Unsupported privilege properties are ignored by the runtime. For bound or unbound actions, the `grant` property is implicitly removed (assuming `grant: '*'` instead). The same is true for functions. This rule ensures that `@restrict.grant` on service level and for bound/unbound actions and functions is limited to `grant: '*'`. ## Examples @@ -36,8 +36,7 @@ Let's consider the following example with the `CatalogService` where the functio #### ❌   Incorrect example -If we were to slightly modify the above example and use `grant: ['WRITE']` in the privilege of the function, the rule would be -triggered to inform us that the value of `grant` is limited to `'*'`: +If you modify the above example and use `grant: ['WRITE']` in the privilege of the function, the rule would be triggered to inform you that the value of `grant` is limited to `'*'`: ::: code-group <<< ../examples/auth-restrict-grant-service/incorrect/srv/cat-service.cds#snippet{cds:line-numbers} [srv/cat-service.cds] diff --git a/tools/cds-lint/rules/auth-use-requires.md b/tools/cds-lint/rules/auth-use-requires.md index 46fabdb84..b6e275b24 100644 --- a/tools/cds-lint/rules/auth-use-requires.md +++ b/tools/cds-lint/rules/auth-use-requires.md @@ -14,7 +14,7 @@ status: released ## Rule Details -Some annotations such as `@requires` or `@readonly` are just convenience shortcuts for `@restrict`. In actions and services with unrestricted events, it is recommended to use `@requires` instead of `@restrict.to`, which this rule enforces. +Some annotations such as `@requires` or `@readonly` are convenience shortcuts for `@restrict`. In actions and services with unrestricted events, it is recommended to use `@requires` instead of `@restrict.to`, which this rule enforces. ## Examples @@ -34,7 +34,7 @@ In the following example, the `CatalogService` action `addRating` correctly uses #### ❌   Incorrect example -In the following example, the `CatalogService` uses `@restrict` to assign unrestricted events (`grant: *`) to the `Admin` role (`to: Admin`). This which could be written more clearly using `@requires` and so the rule reports a warning: +In the following example, the `CatalogService` uses `@restrict` to assign unrestricted events (`grant: *`) to the `Admin` role (`to: Admin`). This could be written more clearly using `@requires` and so the rule reports a warning: ::: code-group <<< ../examples/auth-use-requires/incorrect/srv/cat-service.cds#snippet{cds:line-numbers} [srv/cat-service.cds] diff --git a/tools/cds-lint/rules/auth-valid-restrict-grant.md b/tools/cds-lint/rules/auth-valid-restrict-grant.md index 29d86d386..efa245235 100644 --- a/tools/cds-lint/rules/auth-valid-restrict-grant.md +++ b/tools/cds-lint/rules/auth-valid-restrict-grant.md @@ -14,7 +14,7 @@ status: released ## Rule Details -The `grant` property of a `@restrict` privilege defines one or more events that the privilege applies. This rule checks for valid values of `@restrict.grant`, that is, all standard CDS events (such as `READ`, `CREATE`, `UPDATE`, and `DELETE`) on entities. It also suggests to use `*` only when listing events including `*` and to use `WRITE` only when using solely standard CDS events with write semantics (`CREATE`, `DELETE`, `UPDATE`, `UPSERT`). +The `grant` property of a `@restrict` privilege defines one or more events that the privilege applies to. This rule checks for valid values of `@restrict.grant`, that is, all standard CDS events (such as `READ`, `CREATE`, `UPDATE`, and `DELETE`) on entities. It also suggests using `*` only when listing events including `*` and using `WRITE` only when using solely standard CDS events with write semantics (`CREATE`, `DELETE`, `UPDATE`, `UPSERT`). ## Examples @@ -34,7 +34,7 @@ In the following example, `CatalogService.ListOfBooks` is restricted to the `REA #### ❌   Incorrect example -In the next example, the `@restrict.grant` has a typo in the event (that is, `REAAD` instead of `READ`) for the `Viewer` role, which is not a valid value for `@restrict.grant` so the rule will report a warning: +This example shows the `@restrict.grant` with a typo in the event (that is, `REAAD` instead of `READ`) for the `Viewer` role, which is not a valid value for `@restrict.grant` so the rule will report a warning: ::: code-group <<< ../examples/auth-valid-restrict-grant/incorrect/srv/cat-service.cds#snippet{cds:line-numbers} [srv/cat-service.cds] diff --git a/tools/cds-lint/rules/auth-valid-restrict-keys.md b/tools/cds-lint/rules/auth-valid-restrict-keys.md index 9fe9892f2..c4ae9c948 100644 --- a/tools/cds-lint/rules/auth-valid-restrict-keys.md +++ b/tools/cds-lint/rules/auth-valid-restrict-keys.md @@ -14,7 +14,7 @@ status: released ## Rule Details -To define authorizations on a fine-grained level, the `@restrict` annotation allows you to add all kinds of restrictions that are based on static user roles, the request operation, and instance filters. The building block of such a restriction is a single privilege. This rule checks that the privileges defined in `@restrict` have properly spelled `to`, `grant`, and `where` keys. +To define authorizations on a fine-grained level, the `@restrict` annotation allows you to add all kinds of restrictions based on static user roles, the request operation, and instance filters. The building block of such a restriction is a single privilege. This rule checks that the privileges defined in `@restrict` have properly spelled `to`, `grant`, and `where` keys. ## Examples @@ -34,7 +34,7 @@ In the following example, the `@restrict` annotation on `CatalogService.ListOfBo #### ❌   Incorrect example -In the next example, the `@restrict` annotation on `CatalogService.ListOfBooks` has typos in the `grant` key (`grants` instead of `grant`), the `to` key (`too` instead of `to`), and the `where` key (`were` instead of `where`) and the rule will report them as a warning: +This example shows the `@restrict` annotation on `CatalogService.ListOfBooks` with typos in the `grant` key (`grants` instead of `grant`), the `to` key (`too` instead of `to`), and the `where` key (`were` instead of `where`) and the rule will report them as a warning: ::: code-group <<< ../examples/auth-valid-restrict-keys/incorrect/srv/cat-service.cds#snippet{ts:line-numbers} [srv/cat-service.cds] diff --git a/tools/cds-lint/rules/auth-valid-restrict-to.md b/tools/cds-lint/rules/auth-valid-restrict-to.md index 2276f35bd..e6ac14529 100644 --- a/tools/cds-lint/rules/auth-valid-restrict-to.md +++ b/tools/cds-lint/rules/auth-valid-restrict-to.md @@ -14,7 +14,7 @@ status: released ## Rule Details -The `to` property of a `@restrict` privilege defines one or more [user roles](../../../guides/security/authorization#roles) or [pseudo roles](../../../guides/security/authorization#pseudo-roles) that the privilege applies to. This rule checks that the values of `@restrict.to` are valid, that is, roles cannot be missing, misspelled and that roles including `any` should be simplified to just `any`. +The `to` property of a `@restrict` privilege defines one or more [user roles](../../../guides/security/authorization#roles) or [pseudo roles](../../../guides/security/authorization#pseudo-roles) that the privilege applies to. This rule checks that the values of `@restrict.to` are valid, that is, roles cannot be missing or misspelled and that roles including `any` should be simplified to just `any`. ## Examples @@ -34,7 +34,7 @@ The following example shows a correct usage of the `@restrict.to` annotation, wh #### ❌   Incorrect example -The next example shows the `@restrict.to` annotation being left empty, which is a violation of this rule and a warning is raised: +This example shows the `@restrict.to` annotation being left empty, which is a violation of this rule and a warning is raised: ::: code-group <<< ../examples/auth-valid-restrict-to/incorrect/srv/cat-service.cds#snippet{cds:line-numbers} [srv/cat-service.cds] diff --git a/tools/cds-lint/rules/auth-valid-restrict-where.md b/tools/cds-lint/rules/auth-valid-restrict-where.md index 8abc71bee..a45d84e4b 100644 --- a/tools/cds-lint/rules/auth-valid-restrict-where.md +++ b/tools/cds-lint/rules/auth-valid-restrict-where.md @@ -14,7 +14,7 @@ status: released ## Rule Details -The `where` property of a [`@restrict`](/guides/security/authorization#restrict-annotation) privilege defines a filter expression that restricts the access on an instance level (optional). This rule checks that the values of `@restrict.where` are valid, that is, the filter expression must be a valid expression that compiles without any errors. +The `where` property of a [`@restrict`](/guides/security/authorization#restrict-annotation) privilege defines a filter expression that restricts access on an instance level (optional). This rule checks that the values of `@restrict.where` are valid, that is, the filter expression must be a valid expression that compiles without any errors. ## Examples @@ -34,7 +34,7 @@ In the following example, the `@restrict` privilege is defined with a valid `whe #### ❌   Incorrect example -In the next example, the `@restrict` privilege is defined with an invalid `where` property `CreatedBy === $user`. Since this is not a valid filter expression according to the CDS compiler, the rule reports a warning: +This example shows the `@restrict` privilege defined with an invalid `where` property `CreatedBy === $user`. Since this is not a valid filter expression according to the CDS compiler, the rule reports a warning: ::: code-group <<< ../examples/auth-valid-restrict-where/incorrect/srv/cat-service.cds#snippet{cds:line-numbers} [srv/cat-service.cds] diff --git a/tools/cds-lint/rules/extension-restrictions.md b/tools/cds-lint/rules/extension-restrictions.md index 3ba52c7da..dc3c44b65 100644 --- a/tools/cds-lint/rules/extension-restrictions.md +++ b/tools/cds-lint/rules/extension-restrictions.md @@ -14,10 +14,7 @@ status: released ## Rule Details -CAP provides intrinsic extensibility, which means all your entities and services are extensible by default. -Your SaaS app becomes the base app for extensions by your customers, and your data model the base model. Normally, -you'll want to restrict which services or entities your SaaS customers are allowed to extend and to what degree they may do so. -This rule ensures that extensions do not violate any restrictions set by the extended SaaS app. +CAP provides intrinsic extensibility, which means all your entities and services are extensible by default. Your SaaS app becomes the base app for extensions by your customers, and your data model becomes the base model. Normally, you want to restrict which services or entities your SaaS customers are allowed to extend and to what degree they may do so. This rule ensures that extensions do not violate any restrictions set by the extended SaaS app. ## Examples diff --git a/tools/cds-lint/rules/index.md b/tools/cds-lint/rules/index.md index b89e50377..718e652a0 100644 --- a/tools/cds-lint/rules/index.md +++ b/tools/cds-lint/rules/index.md @@ -16,16 +16,13 @@ Below you can find all rules of the `@sap/eslint-plugin-cds` ESLint plugin. They are grouped by categories [Model Validation](#model-validation), [JavaScript](#javascript), and [Environment](#environment) to help you understand their purpose. -Your standard CDS project configuration turns on a subset of these rules by default, namely the *recommended* -( ✅ ) rules to ensure basic standards are met. +Your standard CDS project configuration turns on a subset of these rules by default, namely the *recommended* ( ✅ ) rules to ensure basic standards are met. ## Model Validation -Model Validation rules are used to validate CDS models within projects. -They are used to enforce security, naming conventions, or other best practices. +Model Validation rules are used to validate CDS models within projects. They are used to enforce security, naming conventions, or other best practices. -Note, that while all recommended ( ✅ ) model rules run with the CLI, only a number of them are -enabled and visible in the editor by default ( 👀 ). +Note that while all recommended ( ✅ ) model rules run with the CLI, only a number of them are enabled and visible in the editor by default ( 👀 ). ::: details * *Editor default* rules: Rules that are enabled in the editor by default only rely on the current file as their rule context. These are quick to execute and can react on file changes. @@ -37,9 +34,7 @@ slow or expensive processes. These are slow to execute and by default only run w ## Environment -Environment rules are used to check for proper and up-to-date CDS project environments. -These are only run via the command line and are not available in the editor as they often can't be -pinpointed to any particular file. +Environment rules are used to check for proper and up-to-date CDS project environments. These run only via the command line and are not available in the editor because they often cannot be pinpointed to any particular file. diff --git a/tools/cds-lint/rules/latest-cds-version.md b/tools/cds-lint/rules/latest-cds-version.md index 6fa9623d2..ff091295f 100644 --- a/tools/cds-lint/rules/latest-cds-version.md +++ b/tools/cds-lint/rules/latest-cds-version.md @@ -14,8 +14,7 @@ status: released ## Rule Details -It's recommended to always use the latest version of `@sap/cds` to benefit from the latest features and bug fixes. -This rule checks whether the latest `@sap/cds` version is being used and reports back in case a newer version is available. +It is recommended to always use the latest version of `@sap/cds` to benefit from the latest features and bug fixes. This rule checks whether the latest `@sap/cds` version is being used and reports back in case a newer version is available. ## Examples diff --git a/tools/cds-lint/rules/no-db-keywords.md b/tools/cds-lint/rules/no-db-keywords.md index ec5f1bc1a..733af92e0 100644 --- a/tools/cds-lint/rules/no-db-keywords.md +++ b/tools/cds-lint/rules/no-db-keywords.md @@ -14,8 +14,7 @@ status: released ## Rule Details -The CDS compiler and CAP runtimes provide smart quoting for reserved words in SQLite so that they can still be used in most situations. -But in general reserved words cannot be used as identifiers and this rule warns you if you use any of the [reserved SQL keywords](https://www.sqlite.org/lang_keywords.html). +The CDS compiler and CAP runtimes provide smart quoting for reserved words in SQLite so they can still be used in most situations. But in general reserved words cannot be used as identifiers and this rule warns you if you use any of the [reserved SQL keywords](https://www.sqlite.org/lang_keywords.html). ## Examples @@ -36,7 +35,7 @@ In the following example, none of the reserved SQL keywords are used as identifi #### ❌   Incorrect example -In the next example, the reserved SQL keyword `Order` is used as an entity name, so the rule will raise a warning: +This example shows the reserved SQL keyword `Order` used as an entity name, so the rule will raise a warning: ::: code-group <<< ../examples/no-db-keywords/incorrect/db/schema.cds#snippet{cds:line-numbers} [db/schema.cds] diff --git a/tools/cds-lint/rules/no-dollar-prefixed-names.md b/tools/cds-lint/rules/no-dollar-prefixed-names.md index e3ccfed5f..5958fe5df 100644 --- a/tools/cds-lint/rules/no-dollar-prefixed-names.md +++ b/tools/cds-lint/rules/no-dollar-prefixed-names.md @@ -34,7 +34,7 @@ In the following example, all elements names are well defined and do not start w #### ❌   Incorrect example -In the next example, the element `$pages` starts with `$` and so the rule will raise an error for this element: +This example shows the element `$pages` that starts with `$` and so the rule will raise an error for this element: ::: code-group <<< ../examples/no-dollar-prefixed-names/incorrect/db/schema.cds#snippet{cds:line-numbers} [db/schema.cds] diff --git a/tools/cds-lint/rules/no-java-keywords.md b/tools/cds-lint/rules/no-java-keywords.md index 911bfb92b..06717d344 100644 --- a/tools/cds-lint/rules/no-java-keywords.md +++ b/tools/cds-lint/rules/no-java-keywords.md @@ -14,9 +14,7 @@ status: released ## Rule Details -The CAP Java code generation bases its class and method names on CDS entities. -If reserved Java keywords are used as CDS identifiers, the code generation or compilation may fail. -This rule helps identify such identifiers early on and suggest to use the `@cds.java.name` annotation. +The CAP Java code generation bases its class and method names on CDS entities. If reserved Java keywords are used as CDS identifiers, the code generation or compilation may fail. This rule helps identify such identifiers early on and suggests using the `@cds.java.name` annotation. ## Examples @@ -37,7 +35,7 @@ In the following example, use of the reserved Java keyword as identifiers is fix #### ❌   Incorrect example -In the next example, the reserved SQL keyword `new` is used as an element name, so the rule will raise a warning: +This example shows the reserved SQL keyword `new` used as an element name, so the rule will raise a warning: ::: code-group <<< ../examples/no-java-keywords/incorrect/db/schema.cds#snippet{cds:line-numbers} [db/schema.cds] diff --git a/tools/cds-lint/rules/no-join-on-draft.md b/tools/cds-lint/rules/no-join-on-draft.md index 618d60fbe..a5f31feb7 100644 --- a/tools/cds-lint/rules/no-join-on-draft.md +++ b/tools/cds-lint/rules/no-join-on-draft.md @@ -34,7 +34,7 @@ In the following example, no draft-enabled entities are used in the service `Cat #### ❌   Incorrect example -In the next example, the service `CatalogService` uses a draft-enabled entity and makes use of `JOIN`, which violates the rule: +This example shows the service `CatalogService` using a draft-enabled entity and making use of `JOIN`, which violates the rule: ::: code-group <<< ../examples/no-join-on-draft/incorrect/srv/cat-service.cds#snippet{cds:line-numbers} [srv/cat-service.cds] diff --git a/tools/cds-lint/rules/sql-cast-suggestion.md b/tools/cds-lint/rules/sql-cast-suggestion.md index b3a44b70a..f9bd060f3 100644 --- a/tools/cds-lint/rules/sql-cast-suggestion.md +++ b/tools/cds-lint/rules/sql-cast-suggestion.md @@ -14,7 +14,7 @@ status: released ## Rule Details -With compiler v2, appending a type declaration to a column expression in a view's query doesn't generate a cast in SQL anymore, as that created conflicts with various database-specific behaviors. This rule ensures that such casts are added explicitly by suggesting possible missing SQL casts. +With compiler v2, appending a type declaration to a column expression in a view's query doesn't generate a cast in SQL anymore because that created conflicts with various database-specific behaviors. This rule ensures that such casts are added explicitly by suggesting possible missing SQL casts. ## Examples @@ -34,7 +34,7 @@ In the following example, the entity `ListOfBooks` contains explicit casts for e #### ❌   Incorrect example -In the next example, the rule will be triggered for elements `name1` and `name2` because they require explicit casts: +This example shows the rule triggered for elements `name1` and `name2` because they require explicit casts: ::: code-group <<< ../examples/sql-cast-suggestion/incorrect/db/schema.cds#snippet{ts:line-numbers} [db/schema.cds] diff --git a/tools/cds-lint/rules/sql-null-comparison.md b/tools/cds-lint/rules/sql-null-comparison.md index dfaf847a3..21246622e 100644 --- a/tools/cds-lint/rules/sql-null-comparison.md +++ b/tools/cds-lint/rules/sql-null-comparison.md @@ -15,8 +15,7 @@ status: released ## Rule Details -Comparing values against `null` in views is a common pitfall in SQL. -This rules helps find places where incorrect SQL comparisons are used and proposes to use `IS NULL` or `IS NOT NULL` instead. +Comparing values against `null` in views is a common pitfall in SQL. This rule helps find places where incorrect SQL comparisons are used and proposes using `IS NULL` or `IS NOT NULL` instead. ## Examples @@ -36,7 +35,7 @@ In the following example, the rule is satisfied because `null` comparison is val #### ❌   Incorrect example -In the next example, the rule reports a warning, because the comparison `= null` is not correct: +This example shows the rule reporting a warning because the comparison `= null` is not correct: ::: code-group <<< ../examples/sql-null-comparison/incorrect/srv/cat-service.cds#snippet{cds:line-numbers} [db/schema.cds] diff --git a/tools/cds-lint/rules/start-elements-lowercase.md b/tools/cds-lint/rules/start-elements-lowercase.md index bfc4fc70b..fdace0981 100644 --- a/tools/cds-lint/rules/start-elements-lowercase.md +++ b/tools/cds-lint/rules/start-elements-lowercase.md @@ -34,7 +34,7 @@ In the following example, the rule is satisfied because the element name `title` #### ❌   Incorrect example -In the next example, the rule will report a warning, because the element name `Title` starts with an uppercase letter: +This example shows the rule reporting a warning because the element name `Title` starts with an uppercase letter: ::: code-group <<< ../examples/start-elements-lowercase/incorrect/db/schema.cds#snippet{ts:line-numbers} [db/schema.cds] diff --git a/tools/cds-lint/rules/start-entities-uppercase.md b/tools/cds-lint/rules/start-entities-uppercase.md index e36b017fc..b6a04ba85 100644 --- a/tools/cds-lint/rules/start-entities-uppercase.md +++ b/tools/cds-lint/rules/start-entities-uppercase.md @@ -35,7 +35,7 @@ In the following example, the rule is satisfied because the entity name `Books` #### ❌   Incorrect example -In the next example, the rule reports a warning, because the entity name `books` starts with a lowercase letter: +This example shows the rule reporting a warning because the entity name `books` starts with a lowercase letter: ::: code-group <<< ../examples/start-entities-uppercase/incorrect/db/schema.cds#snippet{cds:line-numbers} [db/schema.cds] diff --git a/tools/cds-lint/rules/valid-csv-header.md b/tools/cds-lint/rules/valid-csv-header.md index 68145cfee..de9318357 100644 --- a/tools/cds-lint/rules/valid-csv-header.md +++ b/tools/cds-lint/rules/valid-csv-header.md @@ -40,7 +40,7 @@ The following example shows a correct CSV file header that matches the column na #### ❌   Incorrect example -In the next example, there's a typo in the header of the CSV file. The column name `title` is misspelled as `tile`, so the rule reports a warning: +This example shows a typo in the header of the CSV file. The column name `title` is misspelled as `tile`, so the rule reports a warning: ::: code-group <<< ../examples/valid-csv-header/incorrect/db/data/sap.capire.bookshop-Books.csv#snippet{csv:line-numbers{1}} [db/data/sap.capire.bookshop-Books.csv]