44# Author: @ccoVeille
55# License: MIT
66# Variant: 02-basic
7- # Version: v1.1 .0
7+ # Version: v2.0 .0
88#
9+ version : " 2"
10+
11+ formatters :
12+ enable :
13+ # format the code with Go standard library
14+ - gofmt
15+
916linters :
17+ exclusions :
18+ # these presets where present in the v1 version of golangci-lint
19+ # it's interesting to keep them when migrating, but removing them should be the goal
20+ presets :
21+ # exclude check on comments format in godoc
22+ # These are common false positives in poor code
23+ # you should not use this on recent code you write from scratch
24+ # More information: https://golangci-lint.run/usage/false-positives/#comments
25+ - comments
26+
27+ # Common false positives
28+ # feel free to remove this if you don't have any false positives
29+ # More information: https://golangci-lint.run/usage/false-positives/#common-false-positives
30+ - common-false-positives
31+
32+ # Legacy preset is not recommended anymore
33+ # More information: https://golangci-lint.run/usage/false-positives/#legacy
34+ # - legacy
35+
36+ # std-error-handling is a set of rules that avoid reporting unhandled errors on common functions/methods
37+ # More information: https://golangci-lint.run/usage/false-positives/#std-error-handling
38+ - std-error-handling
39+
1040 # some linters are enabled by default
1141 # https://golangci-lint.run/usage/linters/
1242 #
@@ -15,9 +45,6 @@ linters:
1545 # Errcheck is a program for checking for unchecked errors in Go code.
1646 - errcheck
1747
18- # Linter for Go source code that specializes in simplifying code.
19- - gosimple
20-
2148 # Vet examines Go source code and reports suspicious constructs.
2249 - govet
2350
@@ -27,80 +54,107 @@ linters:
2754 # It's a set of rules from staticcheck. See https://staticcheck.io/
2855 - staticcheck
2956
57+ # Checks Go code for unused constants, variables, functions and types.
58+ - unused
59+
3060 # Fast, configurable, extensible, flexible, and beautiful linter for Go.
3161 # Drop-in replacement of golint.
3262 - revive
3363
34- linters-settings :
35- revive :
36- rules :
37- # these are the default revive rules
38- # you can remove the whole "rules" node if you want
39- # BUT
40- # ! /!\ they all need to be present when you want to add more rules than the default ones
41- # otherwise, you won't have the default rules, but only the ones you define in the "rules" node
64+ settings :
65+ revive :
66+ rules :
67+ # these are the default revive rules
68+ # you can remove the whole "rules" node if you want
69+ # BUT
70+ # ! /!\ they all need to be present when you want to add more rules than the default ones
71+ # otherwise, you won't have the default rules, but only the ones you define in the "rules" node
72+
73+ # Blank import should be only in a main or test package, or have a comment justifying it.
74+ - name : blank-imports
75+
76+ # context.Context() should be the first parameter of a function when provided as argument.
77+ - name : context-as-argument
78+ arguments :
79+ - allowTypesBefore : " *testing.T"
4280
43- # Blank import should be only in a main or test package, or have a comment justifying it.
44- - name : blank-imports
81+ # Basic types should not be used as a key in `context.WithValue`
82+ - name : context-keys-type
4583
46- # context.Context() should be the first parameter of a function when provided as argument.
47- - name : context-as-argument
48- arguments :
49- - allowTypesBefore : " *testing.T"
84+ # Importing with `.` makes the programs much harder to understand
85+ - name : dot-imports
5086
51- # Basic types should not be used as a key in `context.WithValue`
52- - name : context-keys-type
87+ # Empty blocks make code less readable and could be a symptom of a bug or unfinished refactoring.
88+ - name : empty-block
5389
54- # Importing with `.` makes the programs much harder to understand
55- - name : dot-imports
90+ # for better readability, variables of type `error` must be named with the prefix `err`.
91+ - name : error-naming
5692
57- # Empty blocks make code less readable and could be a symptom of a bug or unfinished refactoring .
58- - name : empty-block
93+ # for better readability, the errors should be last in the list of returned values by a function .
94+ - name : error-return
5995
60- # for better readability, variables of type `error` must be named with the prefix `err` .
61- - name : error-naming
96+ # for better readability, error messages should not be capitalized or end with punctuation or a newline .
97+ - name : error-strings
6298
63- # for better readability, the errors should be last in the list of returned values by a function.
64- - name : error-return
99+ # report when replacing ` errors.New(fmt.Sprintf())` with `fmt.Errorf()` is possible
100+ - name : errorf
65101
66- # for better readability, error messages should not be capitalized or end with punctuation or a newline.
67- - name : error-strings
102+ # check naming and commenting conventions on exported symbols.
103+ - name : exported
104+ arguments :
105+ # make error messages clearer
106+ - " sayRepetitiveInsteadOfStutters"
68107
69- # report when replacing `errors.New(fmt.Sprintf())` with `fmt.Errorf()` is possible
70- - name : errorf
108+ # incrementing an integer variable by 1 is recommended to be done using the `++` operator
109+ - name : increment-decrement
71110
72- # incrementing an integer variable by 1 is recommended to be done using the `++` operator
73- - name : increment-decrement
111+ # highlights redundant else-blocks that can be eliminated from the code
112+ - name : indent-error-flow
74113
75- # highlights redundant else-blocks that can be eliminated from the code
76- - name : indent-error-flow
114+ # This rule suggests a shorter way of writing ranges that do not use the second value.
115+ - name : range
77116
78- # This rule suggests a shorter way of writing ranges that do not use the second value.
79- - name : range
117+ # receiver names in a method should reflect the struct name (p for Person, for example)
118+ - name : receiver-naming
80119
81- # receiver names in a method should reflect the struct name (p for Person, for example)
82- - name : receiver-naming
120+ # redefining built in names (true, false, append, make) can lead to bugs very difficult to detect.
121+ - name : redefines-builtin-id
83122
84- # redefining built in names (true, false, append, make) can lead to bugs very difficult to detect .
85- - name : redefines-builtin-id
123+ # redundant else-blocks that can be eliminated from the code .
124+ - name : superfluous-else
86125
87- # redundant else-blocks that can be eliminated from the code.
88- - name : superfluous-else
126+ # prevent confusing name for variables when using `time` package
127+ - name : time-naming
89128
90- # prevent confusing name for variables when using `time` package
91- - name : time-naming
129+ # warns when an exported function or method returns a value of an un-exported type.
130+ - name : unexported-return
92131
93- # warns when an exported function or method returns a value of an un-exported type.
94- - name : unexported-return
132+ # spots and proposes to remove unreachable code. also helps to spot errors
133+ - name : unreachable-code
95134
96- # spots and proposes to remove unreachable code. also helps to spot errors
97- - name : unreachable-code
135+ # Functions or methods with unused parameters can be a symptom of an unfinished refactoring or a bug.
136+ - name : unused-parameter
98137
99- # Functions or methods with unused parameters can be a symptom of an unfinished refactoring or a bug.
100- - name : unused-parameter
138+ # report when a variable declaration can be simplified
139+ - name : var-declaration
101140
102- # report when a variable declaration can be simplified
103- - name : var-declaration
141+ # warns when initialism, variable or package naming conventions are not followed.
142+ - name : var-naming
104143
105- # warns when initialism, variable or package naming conventions are not followed.
106- - name : var-naming
144+ output :
145+ # Order to use when sorting results.
146+ # Possible values: `file`, `linter`, and `severity`.
147+ #
148+ # If the severity values are inside the following list, they are ordered in this order:
149+ # 1. error
150+ # 2. warning
151+ # 3. high
152+ # 4. medium
153+ # 5. low
154+ # Either they are sorted alphabetically.
155+ #
156+ # Default: ["file"]
157+ sort-order :
158+ - linter
159+ - severity
160+ - file # filepath, line, and column.
0 commit comments