|
| 1 | +# yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json |
| 2 | +# https://docs.coderabbit.ai/guides/customize-coderabbit |
| 3 | + |
| 4 | +language: "en-GB" |
| 5 | +early_access: true |
| 6 | +reviews: |
| 7 | + request_changes_workflow: true |
| 8 | + high_level_summary: true |
| 9 | + poem: false |
| 10 | + review_status: true |
| 11 | + collapse_walkthrough: false |
| 12 | + auto_review: |
| 13 | + enabled: true |
| 14 | + ignore_title_keywords: |
| 15 | + - "WIP" |
| 16 | + - "DO NOT MERGE" |
| 17 | + - "SWEEP" |
| 18 | + drafts: false |
| 19 | + base_branches: |
| 20 | + - main |
| 21 | + - release/** |
| 22 | + - develop |
| 23 | + path_instructions: |
| 24 | + - path: "*" |
| 25 | + instructions: |
| 26 | + "All character sets need to be in UTF-8.\n |
| 27 | + Lines need to end with LF (line feed).\n |
| 28 | + Spaces need to be utilized for indentation instead of tabs.\n |
| 29 | + A newline must be inserted at the end of the file.\n |
| 30 | + Trim all trailing whitespaces.\n |
| 31 | + Ensure that lines align visually.\n |
| 32 | + Maximum line length must be 120 characters.\n |
| 33 | + Avoid keeping blank lines in code.\n |
| 34 | + Indents on empty lines should not be maintained.\n |
| 35 | + Spaces after commas are required.\n |
| 36 | + Ensure spaces are present around all operators.\n |
| 37 | + Avoid space before comma.\n |
| 38 | + Leftover TODOs in the code should be handled.\n |
| 39 | + Remove any console.log statements.\n |
| 40 | + Name Test Files Descriptively: Adopt the .spec.ts extension and maintain a corresponding filename to |
| 41 | + the source file being tested, and place the test files in the same directory as your source code to |
| 42 | + ensure that new code is being tested promptly.\n |
| 43 | + Describe what Your Test Cases Cover: Use understandable and clear language for both the describe and |
| 44 | + it blocks to specify what function is being tested and what the expected outcome is.\n |
| 45 | + Cover One Aspect in Each Test: While writing tests, make sure each test covers only one aspect of the |
| 46 | + functionality. Multiple assertions can be made but they should be testing the same thing.\n |
| 47 | + Ensure Test Cases Are Independent: Write tests that are independent and can be executed in any order. |
| 48 | + Each test should not rely on other tests.\n |
| 49 | + Avoid Duplication of Logic in Tests: Keep your tests DRY (Don't Repeat Yourself) but don't over |
| 50 | + abstract that it makes the tests hard to understand or follow.\n |
| 51 | + Perform Testing for Edge Cases: Write separate tests for edge cases where the function behaves differently.\n |
| 52 | + Focus on Functionality, not Implementation: Verify the functionality provided by the code, not its |
| 53 | + internal implementation, while testing.\n |
| 54 | + Mock External Dependencies: Mock out external modules and dependencies to ensure each test is isolated\n |
| 55 | + Use beforeEach and afterEach for test Setup and Cleanup.\n |
| 56 | + Ensure Self-Documenting Code: Aim to make your code self-explanatory through clear naming and |
| 57 | + structure. The less time a developer has to spend understanding the code, the better.\n |
| 58 | + Follow the YAGNI Principle: 'You aren't gonna need it' is a principle that prevents developers from |
| 59 | + adding functionality until it is necessary. This can help keep your codebase lean and simple.\n |
| 60 | + Externalizing User-visible Strings: Ensuring all user-facing texts (such as messages, labels, and |
| 61 | + instructions) are sourced from external resource files. This makes it easier to update or translate them |
| 62 | + without having to modify the codebase.\n |
| 63 | + Avoiding Concatenation of Translated Strings: Concatenation might change the meaning of a sentence |
| 64 | + when it is translated to another language due to differences in grammar or sentence structure. Instead, |
| 65 | + use templates or positional parameters." |
| 66 | + |
| 67 | + - path: "**/*.ts" |
| 68 | + instructions: |
| 69 | + "In Typescript files, continuation indent size needs to be 4 spaces.\n |
| 70 | + Multiline array initializer expressions in Typescript must not be aligned.\n |
| 71 | + Binary operations in Typescript across multiple lines should not be aligned.\n |
| 72 | + Multiline chained methods in Typescript should not be aligned.\n |
| 73 | + Extends lists in Typescript across multiple lines should not be aligned.\n |
| 74 | + For loops in Typescript across multiple lines should be aligned.\n |
| 75 | + Parameters in Typescript across multiple lines should be aligned.\n |
| 76 | + Calls in Typescript across multiple lines should not be aligned.\n |
| 77 | + Multiline ternary operations in Typescript should not be aligned.\n |
| 78 | + Object properties and var statements in Typescript should not be aligned.\n |
| 79 | + Binary operation signs in Typescript need to be placed on the next line.\n |
| 80 | + Insert blank lines after imports and around classes, functions, and methods in Typescript.\n |
| 81 | + For 'if' and 'for loops' in Typescript, always use braces.\n |
| 82 | + Avoid placing 'catch' parentheses on a new line in Typescript.\n |
| 83 | + In Typescript, place the chained call dot on a new line.\n |
| 84 | + Remove trailing comma in Typescript.\n |
| 85 | + Union types, binary operations, ternary operations, and var declarations in Typescript need to be |
| 86 | + wrapped on every item.\n |
| 87 | + Binary operations, call parameters, for statements, imports, method parameters, object literals, |
| 88 | + object types, and union types need to be split into lines when wrapped in Typescript.\n |
| 89 | + Spaces after colons, optional parameters, and generator mults are required in Typescript.\n |
| 90 | + Spaces should not be utilized within parentheses but should be utilized within object literal braces in Typescript.\n |
| 91 | + Spaces need to be utilized within array initializer brackets in Typescript.\n |
| 92 | + Explicit types for vars fields, function returns, and function expression returns in TypeScript need to be set.\n |
| 93 | + Space before async arrow left parentheses in TypeScript is required.\n |
| 94 | + Space before function left parentheses and class left brace in Typescript is desirable.\n |
| 95 | + Prefer 'AS' for type casting in TypeScript.\n |
| 96 | + Space is required before method call parentheses in TypeScript.\n |
| 97 | + Space before Method Left Brace needs to be utilized in Typescript.\n |
| 98 | + Space before Switch Parentheses is necessary in Typescript.\n |
| 99 | + Space before Catch Left Brace is required in Typescript.\n |
| 100 | + Utilize space before Catch Parentheses in Typescript.\n |
| 101 | + Space before Catch Keyword is necessary in Typescript.\n |
| 102 | + Make sure to use space before ASync Arrow LeftParen in TypeScript.\n |
| 103 | + Make sure to use space before Type Colon in TypeScript.\n |
| 104 | + Avoid space before Property Colon in TypeScript.\n |
| 105 | + Utilize the space before Colon in TypeScript.\n |
| 106 | + Always prefer 'import type' over 'import' when importing in TypeScript.\n |
| 107 | + Always use 'public' modifier in TypeScript.\n |
| 108 | + Always use property prefix.\n |
| 109 | + Adopt the camelCase convention for naming functions. Ensure the names are clear and descriptive of the |
| 110 | + function's purpose.\n |
| 111 | + Enforce Single Responsibility Principle for every function. Make sure each function performs one task only.\n |
| 112 | + Maintain brevity for functions. Limit each function to about 10-20 lines.\n |
| 113 | + Avoid using too many input parameters for functions. Try to limit input arguments to 3-4. If there are |
| 114 | + more, consider passing an object.\n |
| 115 | + Apply early exits in functions. If a function fails to meet its purpose due to unsatisfied inputs, |
| 116 | + ensure it returns or throws an error early.\n |
| 117 | + Avoid side effects within functions. Don't let a function modify any states or objects beyond its |
| 118 | + scope, it should only depend on input arguments to produce its output.\n |
| 119 | + Implement descriptive variable names within functions.\n |
| 120 | + Address potential errors with measures such as try/catch blocks, error returns, or error callback functions.\n |
| 121 | + If you observe any repeated code, create a new function. If a function becomes too complex, decompose |
| 122 | + it into smaller ones.\n |
| 123 | + Use PascalCase convention for naming classes. Make sure that the names are clear, relevant, and |
| 124 | + communicate the object's purpose.\n |
| 125 | + Adhere to the Single Responsibility Principle. Each class should have one responsibility or task.\n |
| 126 | + Encapsulate data that changes for the same reasons. Variables that are often changed together should |
| 127 | + be placed in the same class to improve data hiding and cohesion.\n |
| 128 | + Implement encapsulation and data hiding. Keep instance variables protected and expose a minimal |
| 129 | + necessary interface to the outside world.\n |
| 130 | + Write methods that operate on an instance's variables. Try to minimize the number of methods that |
| 131 | + access instance variables of other classes.\n |
| 132 | + Ensure classes are immutable wherever possible. An immutable object remains the same across its entire |
| 133 | + lifecycle, improving readability and runtime efficiency.\n |
| 134 | + Use meaningful, descriptive variable and method names. This makes your classes more readable and self-explanatory.\n |
| 135 | + Provide a clear, public API for your classes. It should be clear what methods can be called, what |
| 136 | + parameters they require, and what they will return.\n |
| 137 | + Prefer composition over inheritance. Composition provides better flexibility over inheritance. Avoid |
| 138 | + deep inheritance trees.\n |
| 139 | + Prefer explicit types over implicit types: Wherever possible, explicitly define the type of variables. |
| 140 | + This makes the code more readable and robust to changes.\n |
| 141 | + Use PascalCase for type names: Conventional in many programming communities, PascalCase ensures your |
| 142 | + types are easily distinguished.\n |
| 143 | + Avoid using any type: The any type is a powerful tool in TypeScript for working with dynamic content, |
| 144 | + but regular use can undermine the benefits of type safety.\n |
| 145 | + Use the unknown type for truly unknown types: If you're not sure what type a variable will be, use |
| 146 | + unknown rather than any. This forces you to do type-checking before performing any actions on the variable.\n |
| 147 | + Use type guards for runtime type-checking: Type guards are a way to check the type of an object within |
| 148 | + a conditional statement. Use these to ensure your code is working with the correct types.\n |
| 149 | + Create reusable type definitions: If the same type structure is used in multiple places, create a type |
| 150 | + definition for it.\n |
| 151 | + Use interface to describe object structure: TypeScript's interface keyword allows for powerful OOP techniques.\n |
| 152 | + Use type aliases for complex or compound types: If a type involves unions, intersections, or other |
| 153 | + complex structures, use a type alias to simplify.\n |
| 154 | + Arrays and objects should have types defined: Array items and Object properties must have their types |
| 155 | + clearly defined." |
| 156 | + |
| 157 | + - path: "**/*.json" |
| 158 | + instructions: |
| 159 | + "Indent size for JSON files needs to be 2.\n |
| 160 | + In JSON, an array wrapping needs to be split into lines.\n |
| 161 | + Trailing commas in JSON need to be removed.\n |
| 162 | + Object wrapping in JSON needs to be split into lines.\n |
| 163 | + Avoid alignment of properties in JSON.\n |
| 164 | + Space needs to be introduced after colon and comma in JSON.\n |
| 165 | + Do not introduce space before colon or comma in JSON." |
| 166 | + |
| 167 | +chat: |
| 168 | + auto_reply: true |
0 commit comments