Scribd
Upload
94 views

Project Structure On GitHub

The document discusses common project structure conventions for organizing files in GitHub repositories. It recommends placing source code files in a "src" folder, tests in a "test" folder, documentation in a "docs" folder, compiled files in "build", and tools/utilities in a "tools" folder. Tests are separated from source code to test the program rather than the code. Subfolders under "test" can include "unit", "integration", and "benchmarks".

Uploaded by

Andrew Stifora
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
94 views

Project Structure On GitHub

The document discusses common project structure conventions for organizing files in GitHub repositories. It recommends placing source code files in a "src" folder, tests in a "test" folder, documentation in a "docs" folder, compiled files in "build", and tools/utilities in a "tools" folder. Tests are separated from source code to test the program rather than the code. Subfolders under "test" can include "unit", "integration", and "benchmarks".

Uploaded by

Andrew Stifora
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 4

Project Structure on GitHub

Folder Structure Conventions

A typical top-level directory layout


.
├── build # Compiled files (alternatively `dist`)
├── docs # Documentation files (alternatively `doc`)
├── src # Source files (alternatively `lib` or `app`)
├── test # Automated tests (alternatively `spec` or `tests`)
├── tools # Tools and utilities
├── LICENSE
└── README.md
Use short lowercase names at least for the top-level files and folders
except LICENSE, README.md

Source files
The actual source files of a software project are usually stored inside the src folder.
Alternatively, you can put them into the lib (if you're developing a library), or into
the app folder (if your application's source files are not supposed to be compiled).

Automated tests
Automated tests are usually placed into the test or, less commonly, into
the spec or tests folder.
Q: Why tests are placed into a separate folder, as opposed to having them closer
to the code under test?

A: Because you don't want to test the code, you want to test the program.
.
├── ...
├── test # Test files (alternatively `spec` or `tests`)
│ ├── benchmarks # Load and stress tests
│ ├── integration # End-to-end, integration tests (alternatively `e2e`)
│ └── unit # Unit tests
└── ...
Documentation files
Often it is beneficial to include some reference data into the project, such as Rich Text
Format (RTF) documentation, which is usually stored into the docs or, less commonly,
into the doc folder.
.
├── ...
├── docs # Documentation files (alternatively `doc`)
│ ├── TOC.md # Table of contents
│ ├── faq.md # Frequently asked questions
│ ├── misc.md # Miscellaneous information
│ ├── usage.md # Getting started guide
│ └── ... # etc.
└── ...
Power BI Folder Structure Conventions
.
├── docs # Documentation files (alternatively `doc`)
├── report # Source files (alternatively `lib` or `app`)
├── test # Automated tests (alternatively `spec` or `tests`)
├── tools # Tools and utilities
├── LICENSE
└── README.md
Use short lowercase names at least for the top-level files and folders
except LICENSE, README.md
Python Folder Structure Conventions
.
├── build # Compiled files (alternatively `dist`)
├── docs # Documentation files (alternatively `doc`)
├── src # Source files (alternatively `lib` or `app`)
├── test # Automated tests (alternatively `spec` or `tests`)
├── tools # Tools and utilities
├── LICENSE
└── README.md
Use short lowercase names at least for the top-level files and folders
except LICENSE, README.md

You might also like