low-risk-work.md

low-risk-work.md

Task:

Primary objective:

Low-hanging fruit, low-risk refactoring items that don't follow the Architecture & Structure Guide and Code Style Guide

description

could you look at these documents: /Users/eon/conduit.design/_docs/code_style_guide.md /Users/eon/conduit.design/_docs/architecture_and_structure_guide.md and then scan through the codebase and find lowkey, low-risk, lowhaning fruit things to improve based on these rule sets in these documents.

and then store them in a .md document categoriesed by type. we did this before in this document _docs/_improvements/new_code_quality_improvement_list.md which is now motly complete.

the outstanding items we dont want to fix just yet so dont refind them. alright. try to find around 100 things to fix and store them in a new .md doc. dont fix anything. just stop when the doc is done. also make sure you add file references and line reference to where fixes should be made etc.

store it in a new document called /Users/eon/conduit.design/_docs/code_quality_improvement_list_part_5.md with the same format as _docs/_improvements/new_code_quality_improvement_list_2.md

make sure you group similar types of improvements together under headings, like in the examplle .md docs that i mentioned.

Ignore:

• FIXME Comments Needing Action
• Overly Strong @important Tag
• Code Complexity (Code Style Guide § 9 - Small, focused functions with single responsibilities)
• Unutilized Code/Features (Code Style Guide § 9 - Remove commented code or move to deprecated folder)
• Deprecated Directories and Files
• Code Style Guide § 7.3 - Track technical debt
• Code Quality Standards - Logging Best Practices (Use Logger, not process.stderr.write)
• Code Quality Standards - Commented Code That Should Be Removed
• Documentation Style - FIXME Comments Needing Action
• Code Quality Standards - Refactoring Guidelines
• Logging Inconsistencies: console.log on server
• Large Files > 500 Lines
• complex issues. that is not low hanging fruit.
• Code Style: Redundant void statements ( Code Style Guide § 9 - No commented-out code unless temporarily debugging (similar to dead code))
• Code Quality: Commented-out Code (Code Style Guide § 9 - No commented-out code unless temporarily debugging)
• Inline comments

look for:

• Missing JSDoc File Headers (Code Style Guide § 7.1 - All files should have @fileoverview JSDoc headers)
• Inconsistent Error Handling (Consistent error handling with type checking)
• File Naming Inconsistencies (Class/File Naming Mismatches) Code Style Guide § 2.2 - Match filename to primary export
• Documentation Improvements (Comprehensive JSDoc for all public APIs)
• TypeScript Patterns: Missing explicit function return types
• Imports & Module Boundaries: Deep relative imports
• Error Handling Inconsistencies: Untyped catch blocks ( Code Style Guide § 6 - Consistent error handling with type checking)
• Magic Values: Magic Strings
• Magic Values: Magic Numbers
• Unsafe Type Assertions
• Missing return type Code Style Guide § 4.1 - Always explicitly type function return values
• JSON.parse Without Try-Catch
• simple issues that is low hanging fruit. and won't introduce deeply intertwined regression
• javadoc without param, return, or description
• Missing as const (Arrays or objects used as enums or constant configuration should use as const to infer literal types, providing stricter type safety)
• Type vs Interface Description**: Interfaces are generally preferred for defining object shapes in this project, while types are used for unions, intersections, or primitives.
• Magic Strings That Should Be Constants Guideline: Code Style Guide § 4.3 - Use SCREAMING_SNAKE_CASE constants for magic values
• Documentation Improvements (Code Style Guide § 7 - Comprehensive JSDoc for all public APIs)
• Use of any Types (Code Style Guide § 4.1 - Avoid any without justification; use specific types)
• Missing as const Assertions (TypeScript best practice - Use as const for literal types)
• Inconsistent Catch Block Naming ( Code Style Guide § 6.1 - Standardize on catch (error: unknown) pattern) Files mixing catch (error), catch (e), and catch (err):
• Missing Function Documentation ( Code Style Guide § 7.2 - All exported functions should have JSDoc)
• Missing Return Type Annotations ( Code Style Guide § 4.1 - Always explicitly type function return values)
• Magic Numbers (Code Style Guide § 4.3 - Use named constants for numeric literals)
• Missing JSDoc (Code Style Guide § 7.2 - Exported classes and methods need documentation
• Class/File Naming Mismatches (Code Style Guide § 2.2 - Filename must match primary export)
• Error Handling Inconsistencies: Untyped catch blocks (Code Style Guide § 6.1 - Standardize on catch (error: unknown) pattern)
• Unnecessary @private JSDoc (Code Style Guide § 7.2 - Function documentation should be concise
• Code Style Guide § 6.2 - Error messages should include context)

Structure:

store findings in markdown syntax. each category should have the type of finding. description of the type of finding and a list of file names with line nr where the code of interest is located.

instructions:

IMPORTANT: try to find 10 or so items for each category. totalling around 100-120 items. DO not find more than 10-12 items in any category. Once one category is filled up. stop adding items to it. and look for other categories to fill up. the task is to fill up each category with 10 or so items. So that we cover a wide range of issue categories.