From a239f8142319eb0977d652798960ba0de3ad7dde Mon Sep 17 00:00:00 2001 From: vtchem <74022270+vtchem@users.noreply.github.com> Date: Wed, 6 Jul 2022 23:58:55 +0300 Subject: [PATCH] Update guide-TOC.md --- info/guide/guide-TOC.md | 24 ++++++++++++------------ 1 file changed, 12 insertions(+), 12 deletions(-) diff --git a/info/guide/guide-TOC.md b/info/guide/guide-TOC.md index 3926539583..d1ffb7914c 100644 --- a/info/guide/guide-TOC.md +++ b/info/guide/guide-TOC.md @@ -28,14 +28,14 @@ I [Preface](#c0) * [2.2 Adding comments on the file header](#c2.2) * [2.3 Comments on the function header](#c2.3) * [2.4 Code comments](#c2.4) - * [2.4.1 Add a blank line between the body of the comment and Kdoc tag-blocks](#r2.4.1) + * [2.4.1 Adding a blank line between the body of the comment and Kdoc tag-blocks](#r2.4.1) * [2.4.2 Do not comment on unused code blocks](#r2.4.2) - * [2.4.3 Code delivered to the client should not contain TODO/FIXME comments](#r2.4.3) + * [2.4.3 Code delivered to the client must not contain TODO/FIXME comments](#r2.4.3) [3. General formatting (typesetting)](#c3) * [3.1 File-related rules](#c3.1) * [3.1.1 Avoid files that are too long](#r3.1.1) - * [3.1.2 Code blocks in the source file should be separated by one blank line](#r3.1.2) + * [3.1.2 Code blocks in the source file must be separated by one blank line](#r3.1.2) * [3.1.3 Import statements order](#r3.1.3) * [3.1.4 Order of declaration parts of class-like code structures](#r3.1.4) * [3.1.5 Order of declaration of top-level code structures](#r3.1.5) @@ -50,7 +50,7 @@ I [Preface](#c0) * [3.6.2 Rules for line-breaking](#r3.6.2) * [3.7 Using blank lines](#c3.7) * [3.8 Horizontal space](#c3.8) - * [3.8.1 Usage of whitespace for code separation](#r3.8.1) + * [3.8.1 Using whitespace for code separation](#r3.8.1) * [3.8.2 No spaces for horizontal alignment](#r3.8.2) * [3.9 Enumerations](#c3.9) * [3.10 Variable declaration](#c3.10) @@ -61,7 +61,7 @@ I [Preface](#c0) * [3.13 Block comments](#c3.13) * [3.14 Modifiers and constant values](#c3.14) * [3.14.1 Declaration with multiple modifiers](#r3.14.1) - * [3.14.2 Separate long numerical values with an underscore](#r3.14.2) + * [3.14.2 Separating long numerical values with an underscore](#r3.14.2) * [3.15 Strings](#c3.15) * [3.15.1 Concatenation of Strings](#r3.15.1) * [3.15.2 String template format](#r3.15.2) @@ -73,10 +73,10 @@ I [Preface](#c0) * [4.1 Variables](#c4.1) * [4.1.1 Do not use Float and Double types when accurate calculations are needed](#r4.1.1) * [4.1.2 Comparing numeric float type values](#r4.1.2) - * [4.1.3 Try to use 'val' instead of 'var' for variable declaration [SAY_NO_TO_VAR]](#r4.1.3) + * [4.1.3 Using 'val' instead of 'var' for variable declaration [SAY_NO_TO_VAR]](#r4.1.3) * [4.2 Types](#c4.2) - * [4.2.1 Use Contracts and smart cast as much as possible](#r4.2.1) - * [4.2.2 Try to use type alias to represent types making code more readable](#r4.2.2) + * [4.2.1 Using Contracts and smart cast as much as possible](#r4.2.1) + * [4.2.2 Trying to use type alias to represent types making code more readable](#r4.2.2) * [4.3 Null safety and variable declarations](#c4.3) * [4.3.1 Avoid declaring variables with nullable types, especially from Kotlin stdlib](#r4.3.1) * [4.3.2 Variables of generic types should have an explicit type declaration](#r4.3.2) @@ -93,7 +93,7 @@ I [Preface](#c0) * [5.2.2 Number of function parameters should be limited to five](#r5.2.2) * [5.2.3 Use default values for function arguments instead of overloading them](#r5.2.3) * [5.2.4 Synchronizing code inside asynchronous code](#r5.2.4) - * [5.2.5 Long lambdas should have explicit parameters](#r5.2.5) + * [5.2.5 Long lambdas must have explicit parameters](#r5.2.5) * [5.2.6 Avoid using unnecessary, custom label](#r5.2.6) [6. Classes, interfaces, and extension functions](#c6) @@ -103,13 +103,13 @@ I [Preface](#c0) * [6.1.3 Do not use the primary constructor if it is empty or useless](#r6.1.3) * [6.1.4 Do not use redundant init blocks in your class](#r6.1.4) * [6.1.5 Explicit supertype qualification](#r6.1.5) - * [6.1.6 Abstract class should have at least one abstract method](#r6.1.6) + * [6.1.6 Abstract class must have at least one abstract method](#r6.1.6) * [6.1.7 When using the "implicit backing property" scheme, the name of real and back property should be the same](#r6.1.7) * [6.1.8 Avoid using custom getters and setters](#r6.1.8) * [6.1.9 Never use the name of a variable in the custom getter or setter (possible_bug)](#r6.1.9) * [6.1.10 No trivial getters and setters are allowed in the code](#r6.1.10) * [6.1.11 Use 'apply' for grouping object initialization](#r6.1.11) - * [6.1.12 Prefer Inline classes when a class has a single property](#r6.1.12) + * [6.1.12 Prefer Inline classes when the class has a single property](#r6.1.12) * [6.2 Extension functions](#c6.2) * [6.2.1 Use extension functions for making logic of classes less coupled](#r6.2.1) * [6.2.2 No extension functions with the same name and signature if they extend base and inheritor classes (possible_bug)](#r6.2.2) @@ -117,6 +117,6 @@ I [Preface](#c0) * [6.3 Interfaces](#c6.3) * [6.4 Objects](#c6.4) * [6.4.1 Instead of using utility classes/objects, use extensions](#r6.4.1) - * [6.4.2 Objects should be used for Stateless Interfaces](#r6.4.2) + * [6.4.2 Objects must be used for Stateless Interfaces](#r6.4.2) * [6.5 Kts Files](#c6.5) * [6.5.1 kts files should wrap logic into top-level scope](#r6.5.1)