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

[G-Rath]

@ldez fyi it looks like this linter is not listed in https://golangci-lint.run/usage/linters/

[ldez]

@G-Rath refresh the page: https://golangci-lint.run/usage/linters/#noinlineerr

[ruanxin]

Hi @AlwxSin:

I just noticed your contribution while our team was trying to adopt the latest golangci-lint. First, thanks for your work on this, and I understand the intent behind it, but I’d like to offer a different perspective.

One important advantage of inline error handling is that it limits the scope of the error variable to exactly where it’s relevant. When an error is only used for a single operation, there’s no need to keep it alive in a wider scope. This helps avoid accidental reuse or confusion with unrelated errors, and keeps reasoning about the code more localized.

When inline handling is disallowed, you’re forced to declare a top-level err and reuse it for multiple unrelated calls, which can subtly reduce readability. For example:

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

err = doAnotherThing()
if err != nil {
    return err
}

err = doLastThing()
if err != nil {
    return err
}

Here, a single err variable is reused across unrelated operations, and readers must mentally track its value over a longer stretch of code.

With inline checks, each error is self-contained and unambiguous:

This approach makes it immediately clear where each error came from, and the variable’s scope exactly matches its relevance.

It’s also worth noting that major style guides explicitly recommend inline error handling in certain cases:

Google Code Style – Concision

Uber Go Style Guide – Reduce Scope of Variables

For these reasons, I believe your noinlinerr is basically against those recommendations. It removes a useful language feature that often improves scope control, readability, and maintainability.

cc @ldez, enabling this linter by default really goes against widely known, established style recommendations. Could we at least mark it as not recommended by default?

[bombsimon]

The linter is not enabled by default, no new linters are. If you don't agree with the style (I don't), don't enable the linter.

[ldez]

This linter, like other linters, is related to style.
The style is personal, so I don't want to provide any recommendations about using or not using a linter.

[ruanxin]

Hi @bombsimon @ldez , thanks for the quick feedback.

First, I have to apologise, after checking our golangci.yaml, I realised the issue happened because we have default: all enabled and then selectively disable specific linters. That means when we upgraded, noinlineerr became active automatically.

But this actually highlights a point: our team (and I suspect many others) treat golangci-lint as a trusted guideline for recommended code style. When new linters are added, the implicit expectation is that they are widely recognized, well-accepted, and non-controversial. In this case, as I mentioned earlier, many in the Go community consider banning inline error handling a code smell rather than a style preference, as I mentioned in the Uber’s guideline, which explicitly encourages the opposite.

By including a specific linter, golangci-lint still implicitly signals that this style is worth enforcing, since golangci-lint is trusted by a huge portion of the Go community, that signal matters I believe.

However, if the position of golangci-lint is that style linters are purely neutral and not meant to guide or educate on best practices, then I understand, but that’s a different philosophy than what I think many users expect. Perhaps we’ve simply placed too much expectation on golangci-lint as a de facto style authority, but that expectation is real.

Follow-up question: if someone later proposed a linter that enforces the use of inline error handling, which directly conflicts with this noinlineerr, as it's exactly the opposite style, but is backed by reputable guidelines. Would you accept such linter? If the answer is yes, I probably will contribute to that linter 😄

[AlwxSin]

@ruanxin I completely understand that handling errors inline is largely a matter of personal preference. Personally, I find it harder to read code where errors are inlined, because it shifts the focus from the function call itself to the error handling logic. That’s the main reason why I created this linter.

I also intentionally decided not to enable this linter by default, knowing that in existing codebases this could cause significant issues. In my view, this is a highly opinionated linter, so the decision to enable it should be left entirely to the user.

P.S.I respect the guidelines from Uber and Google, though I see them as recommendations, not mandatory rules, and I prefer a different approach in this case.

[ldez]

golangci-lint is "neutral" but tries not to recommend bad practices.

I would emphasize that the user guides you are quoting don't enforce the usage of error inlining.
They use terms like "Where possible" because always inlining errors is a bad practice.

I have a lot of examples where error inlining created unwanted complexity by hiding factorization or creating shadow declarations.

Always not inlining is not a bad practice; this is just a point of view.

So, I don't think we will accept a linter that forces the usage of error inlining, but you can create a plugin if you want.

https://golangci-lint.run/docs/plugins/module-plugins/

[AlwxSin]

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.

@ruanxin ldez’s comment actually touches on exactly this point — if there is a linter that comprehensively covers all cases of inline if usage and allows enforcing or forbidding any variation, then my noinlineerr linter would become unnecessary.

[bombsimon]

But this actually highlights a point: our team (and I suspect many others) treat golangci-lint as a trusted guideline for recommended code style. When new linters are added, the implicit expectation is that they are widely recognized, well-accepted, and non-controversial.

If so, golangci-linter would only accept linters that would make sense if enabling all linters would be a recommended way. In fact, there are other considerations of not doing that, e.g. #4661 which is about duplicated/overlapping linters. As mentioned, golangci-lint is supposed to be neutral, maybe this is something that could be documented better.

I think the discussion so far has been around how to make sharable presets/sharable standards such as the eslint-config-airbinb has been for JS/TS which would promote styles you like such as Uber or Google style guide.

Some reference to previous issues/discussions where recommended/sharable configuration has been discussed:

• Make and promote recommended and shareable presets like in eslint, tslint #1141
• A good starter .golangci.yml ? #4393 (see the answer here)
• Sharing Configurations Across Repos, VSCode go.linter config #3954
• Add support for remote config file #2137
• Default to YAML when config file has no extension #2618
• Duplication among linters #4661