Skip to main content

Coding Standards

This document establishes project-wide coding standards for all Artbase Studio code. These rules ensure consistency, maintainability, and quality across the entire codebase.

TypeScript / Node Backend​

No any Type​

Never use any in new code.

If a library returns any, define a proper interface/type and cast with as MyType. Prefer unknown + runtime type narrowing over any when the shape is truly dynamic.

❌ Bad
function processData(data: any) {
  return data.name;
}
✅ Good
interface UserData {
  name: string;
  email: string;
}

function processData(data: UserData) {
  return data.name;
}

// Or for truly dynamic data:
function processUnknown(data: unknown) {
  if (typeof data === 'object' && data !== null && 'name' in data) {
    return (data as { name: string }).name;
  }
  throw new Error('Invalid data shape');
}

No Raw Console Logging​

No console.log, console.error, console.warn, or other raw console calls in committed code.

All logging must use structured logging patterns.

❌ Bad
console.log('User created:', userId);
console.error('Payment failed:', error);
✅ Good
// Use proper logging utility
logger.info('user.created', { userId });
logger.error('payment.failed', { error: error.message, userId });

No TODO Placeholders​

No TODO comments or placeholder implementations in production paths.

Do not commit code with // TODO: implement or throw new Error("Not implemented") in routes, services, or controllers that are in active use.

If functionality is genuinely incomplete, either:

  • Complete it before committing
  • Return a proper error response with appropriate HTTP status code
  • Document the limitation in the task's acceptance criteria
❌ Bad
export async function deleteArtist(artistId: string) {
  // TODO: implement artist deletion
  throw new Error('Not implemented');
}
✅ Good
export async function deleteArtist(artistId: string): Promise<void> {
  await prisma.artist.delete({ where: { id: artistId } });
}

No Drive-By Refactors​

Do not rename or restructure existing modules unless explicitly instructed.

Changes should be surgical and focused on the task at hand. If you notice opportunities for improvement, document them for future work rather than changing them immediately.

Follow Existing Formatting​

  • Do not change Prettier/ESLint config except where explicitly specified
  • Follow existing code formatting conventions in the file you're editing
  • Use the configured linter and formatter before committing

Next.js / React​

No any Type​

Same no-any rule as backend TypeScript. Define proper interfaces for props, state, and API responses.

No Raw Console Logging​

Same no console.log / console.error rule as backend. Use structured logging for server-side Next.js code. Client-side errors should be reported through proper error boundaries.

Follow Backend Patterns​

Next.js API routes should follow the same service layer patterns, error handling, and validation as the main backend. Reuse types from shared packages where possible.

No Unauthorized User-Facing Messaging​

NEVER add messaging like "Coming Soon", "Private Beta", "Stay Tuned", etc. without explicit authorization.

Do not make assumptions about product launch status, availability, or marketing messaging. Only add user-facing text that is specifically requested or clearly necessary for functionality.

❌ Bad
<div>
  <h2>Currently in Private Beta</h2>
  <p>We're currently in private beta. Interested in joining?
     Email us at hello@artbase.studio for early access.</p>
</div>
✅ Good
<div>
  <h2>Create your account</h2>
  <p>Start selling your art in minutes</p>
</div>

Component Design​

  • Keep components focused and single-responsibility
  • Extract reusable pieces into separate components
  • Prefer composition over complex conditional rendering

General Standards​

Complete Implementations​

Each task must fully implement all sub-tasks.

Partial implementations are not acceptable. If a task cannot be completed, document why and get user approval before moving on.

No Placeholder Content​

Do not add placeholder content, marketing copy, or assumptions about business decisions.

Only implement what is explicitly requested. When unsure, ask rather than assuming.

Code Quality​

  • Write self-documenting code with clear variable and function names
  • Add comments only where the logic is non-obvious or requires context
  • Prefer small, pure functions over large, stateful ones
  • Handle errors explicitly; avoid silent failures

Testing​

When tests are required, write comprehensive tests covering:

  • Happy paths
  • Error cases
  • Edge cases
  • Integration between components

Ensure tests pass before considering the work complete.

Artbase-Specific Standards​

Color Palette Usage​

Use only the defined Artbase color palette from Tailwind config:

  • soft-sand - Background color
  • ink-charcoal - Primary text and elements
  • studio-coral - Primary accent (CTAs, links)
  • muted-teal - Secondary accent
  • warm-terracotta - Tertiary accent

Typography​

  • Follow the established font hierarchy using Inter
  • Use semantic heading levels (h1, h2, h3, etc.)
  • Maintain consistent spacing and sizing

Authentication​

  • All auth flows use Supabase
  • Server actions for authentication operations
  • Proper redirect handling after auth events
  • Email confirmation required for signup

Respect the three-part ecosystem:

  • Creator Platform (artbase.studio)
  • Gallery Marketplace (gallery.artbase.studio)
  • Artist Storefronts ([name].artbase.studio)

Maintain consistent UX across all three platforms.

How to Use These Standards​

Every task assumes these standards.

If a task appears to conflict with these rules, the more restrictive rule wins:

  • No any always applies
  • No console logging always applies
  • No unauthorized messaging always applies
  • Complete implementations always required

When implementing features, check against this document first. These standards take precedence over convenience or speed.

References​