@@ -30,3 +30,77 @@ linters:
30
30
# Fast, configurable, extensible, flexible, and beautiful linter for Go.
31
31
# Drop-in replacement of golint.
32
32
- revive
33
+
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
42
+
43
+ # Blank import should be only in a main or test package, or have a comment justifying it.
44
+ - name : blank-imports
45
+
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"
50
+
51
+ # Basic types should not be used as a key in `context.WithValue`
52
+ - name : context-keys-type
53
+
54
+ # Importing with `.` makes the programs much harder to understand
55
+ - name : dot-imports
56
+
57
+ # Empty blocks make code less readable and could be a symptom of a bug or unfinished refactoring.
58
+ - name : empty-block
59
+
60
+ # for better readability, variables of type `error` must be named with the prefix `err`.
61
+ - name : error-naming
62
+
63
+ # for better readability, the errors should be last in the list of returned values by a function.
64
+ - name : error-return
65
+
66
+ # for better readability, error messages should not be capitalized or end with punctuation or a newline.
67
+ - name : error-strings
68
+
69
+ # report when replacing `errors.New(fmt.Sprintf())` with `fmt.Errorf()` is possible
70
+ - name : errorf
71
+
72
+ # incrementing an integer variable by 1 is recommended to be done using the `++` operator
73
+ - name : increment-decrement
74
+
75
+ # highlights redundant else-blocks that can be eliminated from the code
76
+ - name : indent-error-flow
77
+
78
+ # This rule suggests a shorter way of writing ranges that do not use the second value.
79
+ - name : range
80
+
81
+ # receiver names in a method should reflect the struct name (p for Person, for example)
82
+ - name : receiver-naming
83
+
84
+ # redefining built in names (true, false, append, make) can lead to bugs very difficult to detect.
85
+ - name : redefines-builtin-id
86
+
87
+ # redundant else-blocks that can be eliminated from the code.
88
+ - name : superfluous-else
89
+
90
+ # prevent confusing name for variables when using `time` package
91
+ - name : time-naming
92
+
93
+ # warns when an exported function or method returns a value of an un-exported type.
94
+ - name : unexported-return
95
+
96
+ # spots and proposes to remove unreachable code. also helps to spot errors
97
+ - name : unreachable-code
98
+
99
+ # Functions or methods with unused parameters can be a symptom of an unfinished refactoring or a bug.
100
+ - name : unused-parameter
101
+
102
+ # report when a variable declaration can be simplified
103
+ - name : var-declaration
104
+
105
+ # warns when initialism, variable or package naming conventions are not followed.
106
+ - name : var-naming
0 commit comments