Wontak Developer Style

Note: Preferences evolve over time. This guide reflects current standards. When working on older projects, check project-specific configurations.

Core Philosophy

Pragmatism Over Purity

Working solutions take priority over theoretical perfection. This doesn't mean cutting corners, but rather choosing practical approaches that deliver value without unnecessary complexity.

Principles:

• •Allow escape hatches (like any type) when genuinely necessary rather than fighting the type system
• •Don't enforce async/await on every function if it adds no value
• •Allow unused parameters in callback signatures to maintain API compatibility
• •Choose the simpler solution when multiple approaches are equally valid

Safety First

Despite embracing pragmatism, safety remains non-negotiable:

• •Strict type checking enabled by default in all TypeScript projects
• •Mutex/lock patterns for any shared mutable state
• •Fail-fast approach for required configuration (crash early, crash loudly)
• •Graceful degradation for optional features (don't crash, log and continue)
• •Design for testability from the start

Clear Intent

Code should communicate its purpose without requiring extensive comments:

• •Use descriptive names that reveal purpose, not implementation
• •Implement explicit state machines with clear guard clauses
• •Use logging as execution documentation
• •Write comments only to explain WHY something is done, never WHAT

Platform Abstraction

When building software that may run on multiple platforms:

• •Core business logic lives in platform-agnostic modules
• •Platform-specific code implements well-defined interfaces
• •Use the Strategy pattern to swap implementations at runtime

Testability by Design

Code should be designed for testability from the beginning. This is more valuable than any coverage metric.

• •Depend on abstractions (interfaces), not concretions
• •Inject dependencies through constructors
• •Avoid static methods and singletons that can't be mocked
• •Keep side effects at the edges of the system
• •Separate pure logic from I/O operations

Quick Reference

Always Do

• •Write all code, comments, and documentation in English
• •Enable strict TypeScript configuration
• •Design for testability from the start
• •Separate platform-agnostic from platform-specific code
• •Specify explicit return types on public methods
• •Use singular folder names
• •Follow conventional commit format
• •Use mutex for shared mutable state
• •Graceful degradation for optional features
• •Fail-fast for required configuration
• •Inject dependencies through constructors
• •Use double quotes in TypeScript/JavaScript

Never Do

• •Chase coverage metrics over meaningful tests
• •Skip return types on public API methods
• •Use plural folder names
• •Commit without conventional format
• •Access platform globals in core code
• •Put business logic in controllers
• •Ignore lint/type errors
• •Use default exports (prefer named exports)
• •Create singletons that can't be mocked

Testing Priority

Pattern Selection Guide

Reference Guide

Load additional references based on your current task:

By Language

By Concern

Common Combinations

Personal development patterns for consistent, maintainable, and testable code.