linters.md

Linting the datadog-agent repository

Welcome to the Datadog Agent linters documentation! Linters are tools that check our source code for errors, bugs, and stylistic inconsistencies. They're essential for maintaining code quality and consistency.

Here are the linters used on the datadog-agent repository depending on the language:

Go

For Go, we're using golangci-lint, a Go linters aggregator. Its configuration is defined in the .golangci.yml file.

The linters key defines the list of linters we're using:

datadog-agent/.golangci.yml

Lines 65 to 79 in dffd326

	linters:
	disable-all: true
	enable:
	- unconvert # Remove unnecessary type conversions
	- unused # Checks Go code for unused constants, variables, functions and types
	- ineffassign # Detects when assignments to existing variables are not used
	- misspell # Finds commonly misspelled English words in comments
	- gofmt # Gofmt checks whether code was gofmt-ed
	- revive # Revive is a replacement for golint, a coding style checker
	- errcheck # errcheck is a program for checking for unchecked errors in go programs.
	- staticcheck # staticcheck is a go vet on steroids, applying a ton of static analysis checks
	- govet # Vet examines Go source code and reports suspicious constructs, such as Printf calls whose arguments do not align with the format string
	- depguard # Depguard is useful for preventing specific packages from being used
	- bodyclose # checks whether HTTP response body is closed successfully
	- gosimple # Linter for Go source code that specializes in simplifying code.

To run the linters locally, run deva linter.go.

Tip

In your code, you can ignore linter issues on a line by prepending it with the nolint directive, for example, //nolint:linter_name. Example here and here.

Python

For Python, we're using (see invoke task):

• ruff, a style linter and a code formatter.
• vulture, to find unused code.

Their configuration is defined in both the setup.cfg and the pyproject.toml files.

To run the linters locally, run deva linter.python.

Tip

In your code, you can ignore linter issues on a line by prepending it with # noqa: error_code. Example here and here.

Troubleshooting

Go

Q: I get a lot of errors locally that I don't get in the CI, why ?

A: This could have several causes:

• Your tool versions are not aligned with ours:
  • go version should output the same as the repository .go-version.
  • golangci-lint --version should output the same as the repository internal/tools/go.mod.
• You're testing OS specific code; running locally, the linters only get the results for your local OS.
• You didn't run deva tidy in the repository, making some dependencies in the remote env outdated compared to your local env.

About the new-from-rev golangci-lint parameter

Introducing the revive linter in the codebase caused hundreds of errors to appear in the CI. As such, the new-from-rev parameter was added to only display linter issues from changes made after the commit that enabled revive. See the Golang documentation for more information.

In a scenario where you have a legacy file hello.go with 100 linter issues, the new-from-rev parameter removes them all. But if you rename the file to hello_world.go, or move it to another folder, all the linter issues reappear. See issue 4349 in the golangci repo for more information.

This case added technical debt so we removed it and used the the nolint directive instead.