Skip to Content
DocumentationCode ReviewBest PracticesGolangCode Placement

Best Practices for Go Project File Placement

Organizing your Go project’s file structure is crucial for maintainability, scalability, and collaboration. Adhering to established conventions not only enhances code readability but also aligns your project with the broader Go community’s expectations. This guide outlines best practices for structuring Go projects at Circle, drawing inspiration from the widely adopted Standard Go Project Layout.

Table of Contents

Introduction

A well-defined project structure facilitates:

  • Clarity: Enables developers to quickly locate files and understand the project’s organization.
  • Maintainability: Simplifies updates, debugging, and collaboration.
  • Scalability: Supports the project’s growth without necessitating significant restructuring.

While Go does not enforce a specific project layout, following community conventions can lead to more predictable and understandable codebases.

Standard Directory Structure

Here is a commonly recommended directory structure for Go projects:

    • go.mod
    • go.sum

/cmd

Contains the main applications for the project. Each subdirectory under /cmd corresponds to a separate executable.

    • main.go
    • init.go

/internal

Houses private application and library code that should not be imported by external projects.

    • app.go
    • app_test.go
    • pubsub.go
    • pubsub_test.go
    • smoke.go

/configs

Contains configuration files and templates. This directory is useful for managing different configurations for various environments (development, staging, production).

    • config.yaml

Ensure that sensitive information is handled securely and consider using environment variables for secrets.

/scripts

Includes build, installation, and deployment scripts. Automating these processes helps maintain consistency across different environments and among team members.

    • build.sh

/build

Contains packaging and continuous integration/deployment configurations. This can include Dockerfiles, packaging scripts, and CI/CD pipeline definitions. Organizing build-related files here keeps them separate from application code.

      • Dockerfile

/deployments

Holds deployment configurations and templates that are used in local and PR builder

    • docker-compose.yaml

/deploy

Holds deployment configurations and templates that are used in staging and production environments.

      • values.yaml

/docs

Includes project documentation, such as design documents, user guides, and manuals. Keeping documentation close to the codebase ensures it stays up-to-date and accessible.

    • architecture.md
Last updated on