code-style

---

description: Code Style Guide globs: src/**/*.ts alwaysApply: false

T6C Effect-TS Code Style Guide

Guidelines for code style in the T6C project using Effect-TS architecture.

Import Patterns

Always Use Relative Paths for Internal Imports

• CRITICAL: Never use src/ aliases for internal imports
• Always use relative paths like ../../stores/blog/blog.store.js
• Use package imports only for external dependencies
• Store files follow pattern: store-name.store.ts

// ✅ CORRECT - Relative paths for internal imports
import { BlogStore } from '../../stores/blog/blog.store.js'
import { getBlogByIdUsecase } from './usecase.js'

// ✅ CORRECT - Package imports for external dependencies
import { BlogPost, BlogPostId } from '@t6c/blog-domain'
import { Effect as E } from 'effect'

// ❌ WRONG - Never use src/ aliases
import { BlogStore } from 'src/stores/blog/blog.store.js'

Comments and Documentation

Avoid Obvious Comments

• NEVER add comments that just repeat what the code is doing
• Only add comments for complex business logic that needs explanation
• Use JSDoc for public APIs, not inline comments for obvious operations

// ✅ CORRECT - No obvious comments, code is self-explanatory
const generatedData = yield* generateBlogPostData(patches)
const updates = createBlogPostPatches(patches, generatedData)
const uniqueSlug = yield* findUniqueSlug(generatedData.slug)

// ❌ WRONG - Obvious comments that add no value
// Generate comprehensive blog post data using AI
const generatedData = yield* generateBlogPostData(patches)
// Create complete patches with generated data
const updates = createBlogPostPatches(patches, generatedData)
// Ensure slug uniqueness
const uniqueSlug = yield* findUniqueSlug(generatedData.slug)

When to Use Comments

• Complex business logic that isn't obvious from function names
• Non-obvious workarounds or edge cases
• Important context that affects future changes
• Never for operations that are clear from function/variable names