@@ -30,3 +30,77 @@ linters:
3030 # Fast, configurable, extensible, flexible, and beautiful linter for Go.
3131 # Drop-in replacement of golint.
3232 - 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