firefart / nonamedreturns Goto Github PK

View Code? Open in Web Editor NEW

24.0 4.0 3.0 4.23 MB

golang linter to detect named returns

License: GNU General Public License v3.0

Makefile 14.67% Go 85.33%

golang go linter lint linting golangci-lint

nonamedreturns's Introduction

nonamedreturns

I hate named returns in golang because they are error prone. That's why I wrote this linter. That's all

Tutorial on how to write your own linter: https://disaev.me/p/writing-useful-go-analysis-linter/

Named errors used in defers are not reported. If you also want to report them set report-error-in-defer to true.

Why are named returns error prone?

Shadowing of Variables
If you have a named return variable that is also used as a local variable within the function, it can lead to shadowing issues. This occurs when the named return variable is unintentionally shadowed by a local variable with the same name, leading to unexpected behavior.
Accidental Changes
Developers might inadvertently modify the value of a named return variable within the function, thinking it only affects the local variable and not the actual return value.
Readability Issues
While named returns can improve readability for method signatures, they can also make the code harder to understand if misused. It may be unclear whether a variable is a local variable or a return variable, especially in larger functions.
Unused Variables
Named returns often result in variables being declared in the function signature that are not used within the function body. This can lead to confusion and may make the code less maintainable.

nonamedreturns's People

Contributors

Stargazers

Watchers

Forkers

xpoh alexchernov ldez

nonamedreturns's Issues

Multiple fields of the same type should be allowed

If you have a function which returns multiple fields of the same type, you need the names to allow the user to understand which return is which, hence this should be allowed by default.

For example:

func Split(path string) (dir, file string)

github.com/firefart/[email protected]: verifying module: checksum mismatch

Hi,

The checksum for this module currently in the module proxy does not match the checksum I get when I try to pull from the repository. This is probably not affecting most people because they use both the official Go proxy cache and official checksum database, but I am trying to populate a local proxy cache cache.

$ GOPROXY=direct go install github.com/firefart/[email protected]
go: downloading github.com/firefart/nonamedreturns v1.0.0
go: github.com/firefart/[email protected]: github.com/firefart/[email protected]: verifying module: checksum mismatch
	downloaded: h1:bP/nIE/jZyMFBIH3LQp5vwqCO4/+Lftxu+DXqRh/3aQ=
	sum.golang.org: h1:TKZUsLIQ7rks6+g5qdG+MAtMIvZEvVSYGNDeybB7jO0=

SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.

For more information, see 'go help module-auth'.

Did you rebase or retag v1.0.0 in the past?

Underscore name should be ignored

Name _ is the same as no name and should be ignored.

func X() (_ error) {
	return
}

Follow Semver

The release (v1.0.4) is not a bugfix release, it's a breaking change: a major version must be created.
Also, the previous release (v1.0.2) was also wrong, because it's not a bugfix release, it's a feature release then it's a minor release.

Semver is essential to provide the right information.

[Good case] Handle errors in defer

I hate named returns too :)

Well, one case are good and should be allowed by linter I suppose.

func f() (retErr error) {
	err := errors.New("foo")
	defer func() {
		if retErr == nil { // <-- analyse and replace returning error
			retErr = errors.New("bar")
		}
	}()
	return err
}

Option to allow naming of return values, but forbid use of them

Names return values are useful for documentation, but problematic when those variables are actually used because of mutation. I would propose a option to the linter to allow naming return values but forbid their use.

Pass

func add(a, b int) (sum int) {
  return a + b
}

func add(a, b int) int {
  return a + b
}

func add(a, b int) int {
  var sum int
  sum = a + b
  return sum
}

Fail

func add(a, b int) (sum int) {
  sum = a + b // error: do not use named return variables
  return sum
}

Difference to `nakedret`?

This linter seems similar to https://github.com/alexkohler/nakedret that has existed and been included in golangci-lint for a while, only without the configurability. I suppose configuring nakedret with max function length 0 would be pretty much the same as this one.

Am I missing something, and/or are there other more substantial differences between the two?