Code Reusability Standards

Before you build anything, ask: "Does this already exist, or will it exist again?" If the answer is yes to either, build it once, build it properly, and reuse it everywhere.

This standard helps decide when UI, logic, validation, services, and platform patterns should become shared assets instead of one-off implementations.

1. Reusability Check Before You Build

Run this check on every task before writing a single line of code or rebuilding an interface block.

If any answer is yes, stop and extract before you build.

2. Reusability Decision Rule

Three or more similar lines means automatic extraction.

3. React / Next.js Reusability

React projects become hard to maintain fast when shared UI, API logic, and validation rules live inline in feature files. Keep the reusable parts in predictable folders and use the same component or schema across the same flow.

What to Make Reusable

Folder Structure

src/
  components/
    ui/
      Button.tsx
      Input.tsx
      Modal.tsx
      Table.tsx
      Badge.tsx
    forms/
      ProjectForm.tsx       ← Used in Add Project AND Edit Project
      MemberInviteForm.tsx
    modals/
      DeleteConfirmModal.tsx
      ConfirmActionModal.tsx

  hooks/
    useProjects.ts
    useWorkspace.ts
    useAuth.ts

  services/
    projects.service.ts
    members.service.ts
    auth.service.ts

  validations/
    project.schema.ts
    member.schema.ts

  utils/
    api-error-handler.ts
    date-formatter.ts
    string-utils.ts

  constants/
    roles.ts
    status.ts
    routes.ts

  types/
    project.ts
    user.ts
    workspace.ts

Anti-Patterns

× Same Button component defined in 5 different files.
× ProjectForm duplicated in AddProject.tsx and EditProject.tsx with different validation.
× fetch('/api/projects') called directly in 8 different components.
× Same error handling logic copy-pasted across every form submit handler.
× Validation rules written inline in each form component.

4. WeWeb Reusability

In WeWeb, reusability means treating recurring UI and behavior as reusable elements, named collections, and shared design tokens instead of rebuilding them per page.

What to Make Reusable

WeWeb Reusability Rules

Naming Reusable Elements

5. Xano Reusability

In Xano, extraction usually means moving repeated multi-step endpoint logic into named functions so permission checks, formatting, logging, and validation stay consistent.

What to Make Reusable

Rule

If you write the same 3+ steps in two different Xano endpoints — extract to a function.

6. Django Reusability

Django work should keep views thin and move repeatable business rules, validation, and template fragments into the layers that are meant to be shared.

What to Make Reusable

Fat Models, Thin Views Rule

View: Handle the HTTP request and response. Not more.
Model/Service: Handle the business logic.
Form/Serializer: Handle validation.
Template: Handle display only.

Bad — business logic in view:

def create_project(request):
    name = request.POST.get('name')
    slug = name.lower().replace(' ', '-')
    existing = Project.objects.filter(slug=slug, workspace=workspace).first()
    if existing:
        ...
    Project.objects.create(name=name, slug=slug, workspace=workspace, created_by=request.user)
    send_email(...)
    log_audit(...)

Good — logic extracted to service:

# services/project_service.py
class ProjectService:
    @staticmethod
    def create_project(workspace, name, created_by):
        slug = generate_slug(name)
        if Project.objects.filter(slug=slug, workspace=workspace).exists():
            raise ConflictError('Project name already exists.')
        project = Project.objects.create(name=name, slug=slug, workspace=workspace, created_by=created_by)
        send_notification(created_by, 'project_created', project)
        AuditLog.log('project.created', actor=created_by, entity=project)
        return project

# views.py
def create_project(request):
    form = ProjectForm(request.POST)
    if not form.is_valid():
        return error_response(form.errors)
    project = ProjectService.create_project(
        workspace=request.workspace,
        name=form.cleaned_data['name'],
        created_by=request.user
    )
    return success_response(project)

7. Supabase Reusability

Supabase reusability shows up in RPC functions, consistent RLS patterns, shared query shapes, and database-level validation that multiple clients can trust.

What to Make Reusable

Reusable RPC Pattern

If the same business operation happens in multiple places (e.g., "create project + create default task + create activity log"), put it in one RPC function — not in three separate frontend calls.

Bad:

// Frontend makes 3 sequential calls
await supabase.from('projects').insert(...)
await supabase.from('tasks').insert(...)
await supabase.from('activity_logs').insert(...)

Good:

// Frontend makes 1 call, backend handles the rest
await supabase.rpc('create_project_with_defaults', { p_workspace_id, p_name })

8. Naming Conventions for Functions

Names must be clear enough that another team member knows what the reusable item does without reading its internal code.

verb_noun or getVerb (for getters)

9. Naming Conventions for Components

PascalCase, named by what it IS

10. Naming Conventions for Hooks

useNoun or useVerbNoun

11. Naming Conventions for Services

noun.service.ts / NounService

12. Reusability Anti-Patterns

These are the most common violations. Watch for all of them.

13. When Not to Over-Abstract

Reusability is good, but over-abstraction creates complexity.

Do not make something reusable if:

× It is only used in one place and has no clear future use.
× Making it "generic" requires more complex parameters than just duplicating it.
× The abstraction would make the code harder to read than the original.
× It is a one-time migration script or throwaway utility.

The rule: Three or more identical uses means extract. One use means keep it local unless the next reuse is obvious.

14. Reusability Checklist Before Marking Done