Coding Conventions¶

Interested in contributing to Pachyderm's code? Learn the conventions here! For setup instructions, see Setup for Contributors.

Languages¶

The Pachyderm repository is written using Go, Shell, and Make. Exceptions to this are:

• /examples: For showcasing how to use the product in various languages.
• /doc: For building documentation using a python-based static site generator (MkDocs).

Shell¶

• See the Shell Style Guide for standard conventions.
• Add set -eou pipefail to your scripts.

Go¶

See the Effective Go Style Guide for standard conventions.

Naming¶

• Consider the package name when naming an interface to avoid redundancy. For example, storage.Interface is better than storage.StorageInterface.
• Do not use uppercase characters, underscores, or dashes in package names.
• The package foo line should match the name of the directory in which the .go file exists.
• Importers can use a different name if they need to disambiguate.
• When multiple locks are present, give each lock a distinct name following Go conventions (e.g., stateLock, mapLock).

Go Modules/Third-Party Code¶

• See the Go Modules Usage and Troubleshooting Guide for managing Go modules.
• Go dependencies are managed with go modules.
• Use go get foo to add or update a package; for more specific versions, use go get foo@v1.2.3, go get foo@master, or go get foo@e3702bed2.

YAML¶

• See the Helm Best Practices guide series.

Review¶

• See the Go Code Review Comments guide for a list of common comments.
• See the Go Test Comments guide for a list of common test code comments.
• Make sure CI is passing for your branch.

Checks¶

• Run checks using make lint.

Testing¶

• All packages and significant functionality must come with test coverage.
• Local unit tests should pass before pushing to GitHub (make localtest or make integration-tests for integrations).
• Use short flag for local tests only.
• Avoid waiting for asynchronous things to happen; If possible, use a method of waiting directly (e.g. 'flush commit' is much better than repeatedly trying to read from a commit).
• Run single tests or tests from a single package; the Go tool only supports tests that match a regular expression (for example, go test -v ./src/path/to/package -run ^TestMyTest).

Documentation¶

• When writing documentation, follow the Style Guide conventions.
• PRs that have only documentation changes, such as typos, is a great place to start and we welcome your help!