From daf23c9e2da2774cd2e7023d0ae920a7981a8dd6 Mon Sep 17 00:00:00 2001
From: Sid <siddharth@usebruno.com>
Date: Tue, 25 Nov 2025 13:30:26 +0530
Subject: [PATCH] feat: add coding standards documentation (#6141)

---
 .coderabbit.yaml    | 66 +++++++++++++++++++++++++++++++++++++++++++++
 CODING_STANDARDS.md | 44 ++++++++++++++++++++++++++++++
 2 files changed, 110 insertions(+)
 create mode 100644 .coderabbit.yaml
 create mode 100644 CODING_STANDARDS.md

diff --git a/.coderabbit.yaml b/.coderabbit.yaml
new file mode 100644
index 000000000..94eb553aa
--- /dev/null
+++ b/.coderabbit.yaml
@@ -0,0 +1,66 @@
+# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json
+
+language: 'en-US'
+early_access: false
+tone_instructions: 'You are an expert code reviewer in TypeScript, JavaScript, NodeJS, and ElectronJS. You work in an enterprise software developer team, providing concise and clear code review advice. You only elaborate or provide detailed explanations when requested.'
+
+knowledge_base:
+  opt_out: false
+  code_guidelines:
+    enabled: true
+    filePatterns:
+      - '**/CODING_STANDARDS.md'
+
+reviews:
+  profile: 'chill'
+  request_changes_workflow: false
+  high_level_summary: true
+  poem: true
+  review_status: true
+  collapse_walkthrough: false
+  auto_review:
+    enabled: true
+    drafts: false
+    base_branches: ['main', 'release/*']
+  path_instructions:
+    - path: 'tests/**/**.*'
+      instructions: |
+        Review the following e2e test code written using the Playwright test library. Ensure that:
+        - Follow best practices for Playwright code and e2e automation
+        - Try to reduce usage of `page.waitForTimeout();` in code unless absolutely necessary and the locator cannot be found using existing `expect()` playwright calls
+        - Avoid using `page.pause()` in code
+        - Use locator variables for locators
+        - Avoid using test.only
+        - Use multiple assertions
+        - Promote the use of `test.step` as much as possible so the generated reports are easier to read
+        - Ensure that the `fixtures` like the collections are nested inside the `fixtures` folder 
+          
+
+
+          **Fixture Example***: Here's an example of possible fixture and test pair
+          ```
+          .
+          ├── fixtures
+          │   └── collection
+          │       ├── base.bru
+          │       ├── bruno.json
+          │       ├── collection.bru
+          │       ├── ws-test-request-with-headers.bru
+          │       ├── ws-test-request-with-subproto.bru
+          │       └── ws-test-request.bru
+          ├── connection.spec.ts # <- Depends on the collection in ./fixtures/collection
+          ├── headers.spec.ts
+          ├── persistence.spec.ts
+          ├── variable-interpolation
+          │   ├── fixtures
+          │   │   └── collection
+          │   │       ├── environments
+          │   │       ├── bruno.json
+          │   │       └── ws-interpolation-test.bru
+          │   ├── init-user-data
+          │   └── variable-interpolation.spec.ts # <- Depends on the collection in ./variable-interpolation/fixtures/collection
+          └── subproto.spec.ts
+          ```
+
+chat:
+  auto_reply: true
diff --git a/CODING_STANDARDS.md b/CODING_STANDARDS.md
new file mode 100644
index 000000000..ab0fe5445
--- /dev/null
+++ b/CODING_STANDARDS.md
@@ -0,0 +1,44 @@
+# Bruno Coding Standards
+
+- No diffs unless an actual change is made, the code changes need to be as minimal as possible, avoid making un-necessary whitespace diffs. This is already handled by eslint but make sure you check your code changes before commiting and raising a PR.
+
+## General Style Rules
+
+- Use 2 spaces for indentation. No tabs, just spaces – keeps everything neat and uniform.
+
+- Stick to single quotes for strings. Double quotes are cool elsewhere, but here we go single.
+
+- Always add semicolons at the end of statements. It's like putting a period at the end of a sentence – clarity matters.
+
+- JSX is enabled, so feel free to use it where it makes sense.
+
+## Punctuation and Spacing
+
+- No trailing commas. Keep it clean, no extra commas hanging around.
+
+- Always use parentheses around parameters in arrow functions. Even for single params – consistency is key.
+
+- For multiline constructs, put opening braces on the same line, and ensure consistency. Minimum 2 elements for multiline.
+
+- No newlines inside function parentheses. Keep 'em tight.
+
+- Space before and after the arrow in arrow functions. `() => {}` is good.
+
+- No space between function name and parentheses. `func()` not `func ()`.
+
+- Semicolons go at the end of the line, not on a new line.
+
+- No strict max length – write readable code, not cramped lines.
+
+- Multiple expressions per line in JSX are fine – flexibility is nice.
+
+Remember, these rules are here to make our codebase harmonious. If something doesn't fit perfectly, let's chat about it. Happy coding! 🚀
+
+## Readability and Abstractions
+
+- Avoid abstractions unless the exact same code is being used in more than 3 places.
+- Names for functions need to be concise and descriptive.
+- Add in JSDoc comments to add more details to the abstractions if needed.
+- Follow functional programming but just enough to be readable, we don't need to go as deep as ADTs and Monads, we want to keep the code pipeline obvious and easy for everyone to read and contribute to.
+- Avoid single line abstractions where all that's being done is increasing the call stack with one additional function.
+- Add in meaningful comments instead of obvious ones where complex code flow is explained properly.