Add noinlineerr linter

[AlwxSin]

Adding noinlineerr linter.

Purpose - allow only one style of error handling.

Instead of:

if err := doSomething(); err != nil {
    return err
}

Prefer more explicit and readable:

err := doSomething()
if err != nil {
    return err
}

[boring-cyborg]

Hey, thank you for opening your first Pull Request !

[CLAassistant]

All committers have signed the CLA.

[ldez]

In order for a pull request adding a linter to be reviewed, the linter and the PR must follow some requirements.

• The CLA must be signed

Pull Request Description

• It must have a link to the linter repository.
• It must provide a short description of the linter.

Linter

• It must not be a duplicate of another linter or a rule of a linter (the team will help to verify that).
• It must have a valid license (AGPL is not allowed), and the file must contain the required information by the license, ex: author, year, etc.
• It must use Go version <= 1.23.0
• The linter repository must have a CI and tests.
• It must use go/analysis.
• It must have a valid tag, ex: v1.0.0, v0.1.0.
• It must not contain init().
• It must not contain panic().
• It must not contain log.Fatal(), os.Exit(), or similar.
• It must not modify the AST.
• It must not have false positives/negatives (the team will help to verify that).
• It must have tests inside golangci-lint.

The Linter Tests Inside Golangci-lint

• They must have at least one std lib import.
• They must have integration tests without configuration (default).
• They must have integration tests with configuration (if the linter has a configuration).

.golangci.next.reference.yml

• The file .golangci.next.reference.yml must be updated.
• The file .golangci.reference.yml must NOT be edited.
• The linter must be added to the lists of available linters (alphabetical case-insensitive order).
  • enable and disable options
• If the linter has a configuration, the exhaustive configuration of the linter must be added (alphabetical case-insensitive order)
  • The values must be different from the default ones.
  • The default values must be defined in a comment.
  • The option must have a short description.

Others Requirements

• The files (tests and linter) inside golangci-lint must have the same name as the linter.
• The .golangci.yml of golangci-lint itself must not be edited and the linter must not be added to this file.
• The linters must be sorted in the alphabetical order (case-insensitive) in the lintersdb/builder_linter.go and .golangci.next.reference.yml.
• The load mode (WithLoadMode(...)):
  • if the linter uses goanalysis.LoadModeSyntax -> no WithLoadForGoAnalysis() in lintersdb/builder_linter.go
  • if the linter uses goanalysis.LoadModeTypesInfo, it requires WithLoadForGoAnalysis() in lintersdb/builder_linter.go
• The version in WithSince(...) must be the next minor version (v2.X.0) of golangci-lint.
• WithURL() must contain the URL of the repository.

Recommendations

• The file jsonschema/golangci.next.jsonschema.json should be updated.
• The file jsonschema/golangci.jsonschema.json must NOT be edited.
• The linter repository should have a readme and linting.
• The linter should be published as a binary (useful for diagnosing bug origins).
• The linter repository should have a .gitignore (IDE files, binaries, OS files, etc. should not be committed)
• A tag should never be recreated.
• use main as the default branch name.

---

The golangci-lint team will edit this comment to check the boxes before and during the review.

The code review will start after the completion of those checkboxes (except for the specific items that the team will help to verify).

The reviews should be addressed as commits (no squash).

If the author of the PR is a member of the golangci-lint team, he should not edit this message.

This checklist does not imply that we will accept the linter.

[AlwxSin]

@ldez thank you for checklist.

Fixed:

• It must use Go version <= 1.23.0
• They must have at least one std lib import.
• The version in WithSince(...) must be the next minor version (v2.X.0) of golangci-lint.
• added .gitignore

Quick question:

The files (tests and linter) inside golangci-lint must have the same name as the linter.

I thought they already do – did I miss something? Could you clarify what exactly should be renamed or matched?

[ldez]

I detected at least one false-positive:

func _() {
	if ok, _ := strconv.ParseBool("1"); ok {
		fmt.Println("ok")
	}
}

The linter is very limited: it only handles explicit error type references, so false negatives can happen.

[ldez]

Even if I don't like inlined if (so this linter is interesting to me), I think the implementation of the linter is too naive.

I don't know what should exactly be implemented, but I think the topic needs to be approached from a broader perspective, maybe with options and more.

[AlwxSin]

@ldez Thanks for the feedback!

Do you have any specific ideas in mind?

Some thoughts I had:

Adding an option to choose the preferred style (though I’m not sure if it makes sense to only prefer the inline variant).

Adding autofix support — though that’s a bit more complex for me at the moment and would need some digging in.

Happy to hear any other suggestions you might have!

[AlwxSin]

@ldez Also, just to clarify — did you mean adding an option like “Check for blank identifiers” (e.g. _ = ...)? Or was it something else?

[AlwxSin]

Hey! 👋 Thanks again for the feedback — I’ve addressed most of the points in the latest update. Here’s what’s changed:

Changes since last review:

Proper type check for error:
Now using types.AssignableTo(...) instead of naive string matching — this catches aliases and other error-compatible types.

Auto-fix support:
For simple cases like if err := foo(); err != nil {} — the linter now suggests and applies a fix.

Avoids false positives:
No more warnings for _ assignments or irrelevant Init cases.

Question: Options?

Right now the linter enforces a strict rule (any inline err := ... triggers a warning).
Do you think it makes sense to introduce config options for more flexibility?

Possible ideas:

allow-inline-in-tests: true
Ignore inline error handling in _test.go files.

allow-multi-assign: true
Allow if x, err := foo(); err != nil {} (only warn on single err := cases).

Let me know if you think this is worth exploring, or if the linter should stay strict and opinionated.

[ldez]

The proposed options are not what I expected.

• allow-inline-in-tests will not be used by golangci-lint because this must be handled inside the golangci-lint exclusions and not a the linter level.
• allow-multi-assign I don't see why this should be a specific topic.

I'm talking about a broader perspective of inlined if, not to the restricted scope of errors.

[AlwxSin]

About the broader perspective — I get your point, but I’d prefer to keep the scope limited to err := ... cases for now.
This is where most readability issues tend to show up in practice, and it matches the linter's intent (and name — noinlineerr).

I’ve often seen inline error handling being overused or misused, whereas inline Init with other values is way less common —
so I focused on the pattern that was actually causing pain in the codebases I work with.

That said, building a separate linter to cover all inline Init statements (if x := ...; cond {}) could definitely be interesting —
but that feels like a broader concern and a different project altogether.

[ldez]

ok, so we agree that if a new linter is added that handles the whole topic of inlined if, your linter will be deprecated inside golangci-lint and removed.

If we agree on that, we can accept this linter.

[AlwxSin]

Totally agree

[ldez]

LGTM