From 280ab920a8129248f536d4a49b53d5c71ba340f1 Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Bartek=20Iwa=C5=84czuk?= Date: Fri, 6 Nov 2020 17:36:28 +0100 Subject: docs: Update style guide (#8267) --- docs/contributing/style_guide.md | 19 +++++-------------- 1 file changed, 5 insertions(+), 14 deletions(-) (limited to 'docs/contributing') diff --git a/docs/contributing/style_guide.md b/docs/contributing/style_guide.md index 9b75c09ba..3f190ecf3 100644 --- a/docs/contributing/style_guide.md +++ b/docs/contributing/style_guide.md @@ -279,20 +279,11 @@ the first column of the comment. For example: Code examples should not contain additional comments. It is already inside a comment. If it needs further comments it is not a good example. -### Resolve linting problems using ESLint directives +### Resolve linting problems using directives -Currently, the building process uses ESLint to validate linting problems in the -code. Don't use `deno_lint` directives while working with internal Deno code and -the std library. - -What would be: - -```typescript -// deno-lint-ignore no-explicit-any -let x: any; -``` - -Should rather be: +Currently, the building process uses `dlint` to validate linting problems in the +code. If the task requires code that is non-conformant to linter use +`deno-lint-ignore ` directive to supress the warning. ```typescript // deno-lint-ignore no-explicit-any @@ -300,7 +291,7 @@ let x: any; ``` This ensures the continuous integration process doesn't fail due to linting -problems. +problems, but it should be used scarcely. ### Each module should come with a test module. -- cgit v1.2.3