-
Notifications
You must be signed in to change notification settings - Fork 4
/
Copy path.revive.toml
256 lines (211 loc) · 8.42 KB
/
.revive.toml
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
## Trivial Tickets Ticketsystem
## Copyright (C) 2019 The Contributors
##
## This program is free software: you can redistribute it and/or modify
## it under the terms of the GNU General Public License as published by
## the Free Software Foundation, either version 3 of the License, or
## (at your option) any later version.
##
## This program is distributed in the hope that it will be useful,
## but WITHOUT ANY WARRANTY; without even the implied warranty of
## MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
## GNU General Public License for more details.
##
## You should have received a copy of the GNU General Public License
## along with this program. If not, see <http://www.gnu.org/licenses/>.
##
##
## Ticketsystem Trivial Tickets
##
## Matriculation numbers: 3040018, 6694964, 3478222
## Lecture: Programmieren II, INF16B
## Lecturer: Herr Prof. Dr. Helmut Neemann
## Institute: Duale Hochschule Baden-Württemberg Mosbach
##
## ---------------
## Revive Configuration and Rule Set
##
# --- Default Configuration ---
# ==============================
# When set to false, ignores files with "GENERATED"
# header, similar to golint
ignoreGeneratedHeader = false
# Sets the default severity to "warning"
severity = "warning"
# Sets the default failure confidence. This means
# that linting errors with less than 0.8 confidence
# will be ignored.
confidence = 0.8
# Sets the exit code for failures with
# severity "error"
errorCode = 1
# Sets the exit code for failures with
# severity "warning"
warningCode = 0
# --- Linting Rules ----
# ==============================
# Suggests using constant for magic numbers and
# string literals. See also
# https://en.wikipedia.org/wiki/Magic_number_(programming)#Unnamed_numerical_constants.
[rule.add-constant]
arguments = [{maxLitCount = "5", allowStrs = "\"\"", allowInts = "0,1,2", allowFloats = "0.0,0.,1.0,1.,2.0,2."}]
# Warns when a function receives more parameters than
# the maximum set by the rule's configuration. Enforcing
# a maximum number of parameters helps to keep the code
# readable and maintainable.
[rule.argument-limit]
arguments = [5]
# Blank import should be only in a main or test package,
# or have a comment justifying it.
[rule.blank-imports]
# Methods or fields of `struct` that have names different
# only by capitalization could be confusing.
[rule.confusing-naming]
# Function or methods that return multiple, no named,
# values of the same type could induce error.
[rule.confusing-results]
# By convention, `context.Context` should be the first
# parameter of a function. This rule spots function
# declarations that do not follow the convention. See
# also https://github.com/golang/go/wiki/CodeReviewComments#contexts.
[rule.context-as-argument]
# Basic types should not be used as a key in
# `context.WithValue`.
[rule.context-keys-type]
# Cyclomatic complexity is a measure of code complexity.
# Enforcing a maximum complexity per function helps to
# keep code readable and maintainable. Here we specify
# that the rule should fail if it detects code with
# higher complexity than 10.
[rule.cyclomatic]
arguments = [10]
# Packages exposing functions that can stop program
# execution by exiting are hard to reuse. This rule
# looks for program exits in functions other than
# `main()` or `init()`.
[rule.deep-exit]
# Importing with `.` makes the programs much harder
# to understand because it is unclear whether names
# belong to the current package or to an imported
# package. More information here:
# https://github.com/golang/go/wiki/CodeReviewComments#import-dot.
[rule.dot-imports]
severity = "error"
# Empty blocks make code less readable and could be
# a symptom of a bug or unfinished refactoring.
[rule.empty-block]
# By convention, for the sake of readability, variables
# of type `error` must be named with the prefix `err`.
[rule.error-naming]
# By convention, for the sake of readability, the errors
# should be last in the list of returned values by a
# function.
[rule.error-return]
# By convention, for better readability, error messages
# should not be capitalized or end with punctuation or
# a newline. More information here:
# https://github.com/golang/go/wiki/CodeReviewComments#error-strings.
[rule.error-strings]
# It is possible to get a simpler program by replacing
# `errors.New(fmt.Sprintf())` with `fmt.Errorf()`. This
# rule spots that kind of simplification opportunities.
[rule.errorf]
# Exported function and methods should have comments.
# This warns on undocumented exported functions and
# methods.
[rule.exported]
# This rule helps to enforce a common header for all
# source files in a project by spotting those files
# that do not have the specified header.
[rule.file-header]
arguments = ["Trivial Tickets Ticketsystem"]
# If a function controls the flow of another by passing
# it information on what to do, both functions are said
# to be control-coupled. Coupling among functions must
# be minimized for better maintainability of the code.
# This rule warns on boolean parameters that create a
# control coupling.
[rule.flag-parameter]
# Functions returning too many results can be hard to
# understand/use.
[rule.function-result-limit]
arguments = [3]
# Typically, functions with names prefixed with Get are
# supposed to return a value.
[rule.get-return]
# Checking if an error is nil to just after return the
# error or nil is redundant.
[rule.if-return]
# Warns when importing black-listed packages.
[rule.imports-blacklist]
arguments = ["crypto/md5", "crypto/sha1"]
# By convention, for better readability, incrementing
# an integer variable by 1 is recommended to be done
# using the `++` operator. This rule spots expressions
# like `i += 1` and `i -= 1` and proposes to change them
# into `i++` and `i--`.
[rule.increment-decrement]
# To improve the readability of code, it is recommended
# to reduce the indentation as much as possible. This
# rule highlights redundant else-blocks that can be
# eliminated from the code.
[rule.indent-error-flow]
# A method that modifies its receiver value can have
# undesired behavior. The modification can be also
# the root of a bug because the actual value receiver
# could be a copy of that used at the calling site.
# This rule warns when a method modifies its receiver.
[rule.modifies-value-receiver]
# Packages should have comments. This rule warns on
# undocumented packages and when packages comments
# are detached to the package keyword.
[rule.package-comments]
# This rule suggests a shorter way of writing ranges
# that do not use the second value.
[rule.range]
# By convention, receiver names in a method should
# reflect their identity. For example, if the receiver
# is of type `Parts`, `p` is an adequate name for it.
# Contrary to other languages, it is not idiomatic
# to name receivers as `this` or `self`.
[rule.receiver-naming]
# Constant names like `false`, `true`, `nil`, function
# names like `append`, `make`, and basic type names
# like `bool`, and `byte` are not reserved words of
# the language; therefore they can be redefined. Even
# if possible, redefining these built-in names can lead
# to bugs very difficult to detect.
[rule.redefines-builtin-id]
severity = "error"
# To improve the readability of code, it is recommended
# to reduce the indentation as much as possible. This
# rule highlights redundant `else`-blocks that can be
# eliminated from the code.
[rule.superfluous-else]
# Using unit-specific suffix like "Secs", "Mins", ...
# when naming variables of type `time.Duration` can be
# misleading, this rule highlights those cases.
[rule.time-naming]
# This rule warns when an exported function or method
# returns a value of an unexported type.
[rule.unexported-return]
# This rule suggests to remove redundant statements
# like a `break` at the end of a `case` block, for
# improving the code's readability.
[rule.unnecessary-stmt]
# This rule spots and proposes to remove unreachable
# code. More information here:
# https://en.wikipedia.org/wiki/Unreachable_code.
[rule.unreachable-code]
# This rule warns on unused parameters. Functions or
# methods with unused parameters can be a symptom of
# an unfinished refactoring or a bug.
[rule.unused-parameter]
# This rule proposes simplifications of variable
# declarations.
[rule.var-declaration]
# This rule warns when variable or package naming
# conventions are not followed. See
# https://github.com/golang/go/wiki/CodeReviewComments#variable-names
# for variable and package name conventions.
[rule.var-naming]