Folder structure and project names

Guidelines for the layout and structure of a scalable, readable codebase

Root folder structure

A git repository should contain some (or all) of the following root-level folders:

Folder	Purpose
build	Build configuration and tooling Developer-written scripts, configuration files, environment setup files, and utilities to automate and orchestrate build-related tasks such as linting, compiling, bundling, transforming, and deploying source code.
config	Project configuration files Configuration files, environment settings, dependency injection configuration, etc.
data	Project datasets Seed data for initialization, example datasets, and/or persistent project data
dist	Build output artifacts Compiled, bundled, and/or generated files produced by the build process. This folder represents the deployable or distributable form of the project. (It should be excluded from version control.)
docs	Project documentation Technical documentation related to the project. Includes markdown files, HTML files, API references, user guides, architecture overviews, or other documents that provide instructions, tutorials, and reference materials for developers.
public	Static web-visible resources Static files used in the project and intended to be publicly accessible. These might include images, icons, fonts, HTML/CSS/JS files, and other media assets.
src	Application source code Source code files for the project. Subfolder Purpose api Backend services and applications that expose data and functionality via HTTP APIs. These projects handle server-side logic, routing, and integrations. cli Command-line applications that provide tooling and automation for developers and operators. These apps interact with other services, scripts, and local resources. lib Libraries that encapsulate reusable logic, types, and domain models — intended for use in other projects rather than being used directly. test Libraries and applications specifically designed for testing, validation, and benchmarking to ensure code correctness, performance, and integration coverage. web Frontend user-facing applications and sites rendered in a browser.
assets	(Optional) Private static resources used in the project and not intended to be publicly accessible. These might include images, fonts, and other media files.
source	(Optional) Source code files that specifically target Microsoft .NET Framework 4.8. This is not necessarily legacy code, therefore the term “legacy” is normally avoided. (This is intentionally separated from other source code because .NET Framework 4.8 projects are difficult to work with using VS Code.)

Source code project names

The name of a source code project that targets .NET uses Pascal Case: the first letter of each word in a multi-word identifier is capitalized, and there are no spaces or separators between words.

Use dots in the project name (as needed) to indicate architectural boundaries. For example:

• src/api/DanielMiller.Api

• src/cli/Workday.Integration

• src/lib/Shift.Assessment.Sdk