LogoLogo
  • Technical Direction
  • Technical overview
    • Technical Implementation
    • API Design Guide
      • Data Definitions and Standards
      • Data Transfer Objects
      • Documentation
      • Environments
      • Error Handling
      • Example API Service
      • GraphQL Naming Conventions
      • Methods
      • Naming Conventions
      • Once Only Principle
      • Pagination
      • Resource Oriented Design
      • REST Request
      • REST Response
      • Security
      • Versioning
    • Ísland.is Public Web Data Flow
    • Code Reviews
    • Code Standards
    • Monorepo
    • Project Management
    • Teamwork
    • Architectural Decision Records
      • Use Markdown Architectural Decision Records
      • Use NX
      • Continuous Integration
      • CSS
      • Branching and Release Strategy
      • Error Tracking and Monitoring
      • What API Management Tool to Consider
      • Viskuausan Static Site Generator
      • Use OAuth 2.0 and OpenID Connect As Protocols for Authentication and Authorization
      • Unified Naming Strategy for Files and Directories
      • CMS
      • Open Source License
      • What Chart Library Should We Use Across Island.is?
      • What Feature Flag Service/application Should We Use at Island.is?
      • Logging, Monitoring and APM Platform
      • ADR Template
    • Log Management Policy
  • Products
    • Island.is Authentication Service
      • Terminology
      • Integration Options
      • Authentication Flows
      • Authorising API Endpoints
      • Session Lifecycle
      • Scopes and Tokens
      • Delegations
      • Configuration
      • Tools and Examples
      • Environments
      • Test IAS with Postman
      • Using the IAS admin portal
    • Notifications / Hnipp
      • New Notification Setup Guide
      • Notifications service workflow overview
      • Email notifications
    • Pósthólfið
      • Security Checklist
      • Introduction
      • Skjalatilkynning API
      • Skjalaveita API
      • Sequence Diagram
      • Interfaces
    • Straumurinn (X-Road)
      • Architecture Guidelines for Service Providers and Consumers
      • Setting up an X-Road Security Server
        • Network Configuration
      • X-Road - Uppfærsla á öryggisþjónum
      • Straumurinn - Notkun og umsýsla
      • X-Road Central - current version
  • Development
    • Getting Started
    • Generating a New Project
    • Definition of done
    • Devops
      • Continuous Delivery
      • Database
      • Dockerizing
      • Environment Setup
      • Logging
      • Metrics
      • NextJS Custom Server
      • Observability
      • Operations Base Principles
      • Security
      • Service Configuration
      • Support
    • AWS Secrets
    • Feature Flags
    • Documentation Contributions
    • Defining Monorepo Boundaries With Tags
    • OpenAPI
    • Code Generation
    • Workspace Settings (Deprecated)
    • External Contributions
  • REFERENCE
    • Problems
      • 400 Validation Failed
      • 400 Attempt Failed
      • 403 Bad Subject
      • 400 500 Template API Error
    • Glossary
  • Misc
    • Guide: Adding a Payment Step to an Application
    • Guide: Enable Organisations to Make Requests to an Application
    • README Template
Powered by GitBook
On this page
  • Context and Problem Statement
  • Decision Drivers
  • Considered Options
  • Decision Outcome
  • Positive Consequences

Was this helpful?

  1. Technical overview
  2. Architectural Decision Records

Unified Naming Strategy for Files and Directories

  • Status: accepted

  • Deciders: devs

  • Date: 2020-07-03

Context and Problem Statement

As of the date of this writing, there are multiple different naming styles used in the monorepo, mostly because NX has defaults that differ between schematic types. In order for navigating the monorepo in a consistent rational manner, we should align on naming strategy for files and directories.

Decision Drivers

  • Provide consistency when navigating the codebase

  • The earlier we decide on this, the better

Considered Options

Some mixture of these:

  • kebab-case

  • PascalCase

  • camelCase

  • snake_case

Decision Outcome

Chosen option: Name files after their default export. If that default export is a React Component, or a class, then the file name should be in PascalCase. Otherwise, the filename should be in camelCase. Basically, for naming files avoid using kebab-case and snake_case and make sure the name follows the default export of the file.

Naming directories should follow these guidelines: Only use kebab-case when naming NX apps and libraries, or folders containing apps and libraries, e.g. island-ui instead of islandUi: import { Box } from '@island.is/island-ui/core'

Use PascalCase for directories only containing React components:

components/CtaButton/index.ts
import 'components/CtaButton'

or:

components/CtaButton/CtaButton.tsx
import 'components/CtaButton/CtaButton'

rather than

components/cta-button/CtaButton.tsx

In all other cases, use camelCase.

Positive Consequences

  • Easier to navigate the codebase

  • File names are more readable, and developers know what to expect

  • This approach is the most common practice, and something most JS and TS developers are familiar with.

PreviousUse OAuth 2.0 and OpenID Connect As Protocols for Authentication and AuthorizationNextCMS

Last updated 2 years ago

Was this helpful?