Source code analyzer that helps you to make your Go programs more consistent.
Switch branches/tags
Nothing to show
Clone or download
Quasilyte remove redundant lambda wrapper
Found by unlambda check from gocritic linter

Signed-off-by: Iskander Sharipov <>
Latest commit 165adc4 Dec 7, 2018


Source code analyzer that helps you to make your Go programs more consistent.

Quick start / Installation

This install go-consistent binary under your $GOPATH/bin:

go get

If $GOPATH/bin is under your system $PATH, go-consistent command should be available after that.
This should print the help message:

go-consistent --help

You can pass package names and separate Go filenames to the go-consistent tool:

go-consistent foo.go bar.go mypkg

You can also use std, ./... and other conventional targets that are normally understood by Go tools.

  • If you want to check consistency of a single file or package, just provide their name
  • If you want to check the whole project, you should pass all its packages as an arguments

Suppose your project occupies separate $GOPATH, then you can check the entire project by doing:

cd $(go env GOPATH)/src
go-consistent -v ./...


To understand what go-consistent does, take a look at these 3 lines of code:

lit1 := map[K]V{}
lit2 := map[K]V{}
m := make(map[K]V)

lit1, lit2 and m are initialized to an empty, non-nil map. The problem is that you have at least 2 ways to do it:

  1. lit1 and lit2 use the first option, the map literal
  2. m uses the second option, the make function

Neither of these are the "best", but on the package or project level, you might want to prefer only one of them, for consistency reasons.

go-consistent tool detects that map literal used more frequently (2 vs 1) in the example above, so it suggest you to replace m initialization expression to use map literal instead of make function.

There are many similar cases where you have 2 or more options of expressing the same thing in Go, go-consistent tries to handle as much patterns as possible.

Project traits

  • Zero-configuration. Defaults should be good enough for most users. Other configuration is performed using command line arguments.
  • Can handle projects of any size. This means that there should be no significant memory consumption growth with the increased number of packages being checked. There can be "fast, but memory-hungry" option that can work best for small-average projects, but it should be always possible to check huge projects on the developer machine.

Complete list of checks performed

  1. unit import
  2. zero val ptr alloc
  3. empty slice
  4. empty map
  5. hex lit
  6. range check
  7. and-not
  8. float lit
  9. label case
  10. untyped const coerce
  11. arg list parens
  12. non-zero length test
  13. default case order

unit import

// A: no parenthesis
import "fmt"

// B: with parenthesis
import (

zero val ptr alloc

// A: new call

// B: address of literal

empty slice

// A: make call
make([]T, 0)

// B: slice literal

empty map

// A: make call

// B: map literal

hex lit

// A: lower case a-f digits

// B: upper case A-F digits

range check

// A: left-aligned
x > low && x < high

// B: center-aligned
low < x && x < high


// A: using &^ operator (no space)
x &^ y

// B: using & and ^ (with space)
x & ^y

float lit

// A: explicit int/frac parts

// B: implicit int/frac parts

label case

// A: all upper case

// B: upper camel case

// C: lower camel case

untyped const coerce

// A: LHS type
var x int32 = 10
const y float32 = 1.6

// B: RHS type
var x = int32(10)
const y = float32(1.6)

arg list parens

// A: closing parenthesis on the same line

// B: closing parenthesis on the next line

non-zero length test

// A: compare as "number of elems not equal to zero"
len(xs) != 0

// B: compare as "more than 0 elements"
len(xs) > 0

// C: compare as "at least 1 element"
len(xs) >= 1

default case order

// A: default case is the first one
switch {
	return "?"
case x > 10:
	return "more than 10"

// B: default case is the last one
switch {
case x > 10:
	return "more than 10"
	return "?"