-
Notifications
You must be signed in to change notification settings - Fork 4
/
.rubocop.yml
222 lines (182 loc) · 6.8 KB
/
.rubocop.yml
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
AllCops:
TargetRubyVersion: 2.3
Include:
- 'Rakefile'
Exclude:
- Gemfile
Metrics/LineLength:
Max: 140
# Removes the requirement for using double quotes only for string interpolation.
Style/StringLiterals:
Enabled: true
# These complexity and length metrics tend to require a bunch of high-touch refactoring
# in existing projects. Leaving them high for now, and we can slowly lower them to standard
# levels in the near future.
Metrics/ModuleLength:
Max: 200
Metrics/ClassLength:
Max: 230
Metrics/MethodLength:
Max: 50
Metrics/BlockLength:
Max: 500
Metrics/AbcSize:
Max: 75
Metrics/CyclomaticComplexity:
Max: 20
Metrics/PerceivedComplexity:
Max: 20
# Allow long keyword parameter lists
Metrics/ParameterLists:
Max: 15
CountKeywordArgs: false
# This enforces bad style and can break things.
# See: https://github.com/bbatsov/rubocop/issues/2614
Performance/Casecmp:
Enabled: false
# This requires the use of alias rather than alias_method, which seems totally arbitrary
Style/Alias:
Enabled: false
# This cop enforces that submodules/subclasses be defined like this:
#
# class Foo::Bar
#
# rather than like this:
#
# module Foo
# class Bar
#
# This is actually semantically different, and there are valid reasons for wanting to use the latter
# form because of the way the former does funky stuff to the namespace.
Style/ClassAndModuleChildren:
Enabled: false
# This forces you to use class instance variables rather than class variables, which seems pretty
# situation-specific
Style/ClassVars:
Enabled: false
# This makes you do things like this:
# variable = if test
# 'abc-123'
# else
# 'def-456'
# end
#
# I think this is harder to read than assigning the variable within the conditional.
Style/ConditionalAssignment:
Enabled: false
# This cop forces you to put a return at the beginning of a block of code rather than having an if statement
# whose body carries to the end of the function. For example:
#
# def foo
# ...
# if test
# ...
# end
# end
#
# would be considered bad, and the cop would force you to put a `return if !test` before that block and
# then remove the if. The problem is that this hides intent, since the if test does have a purpose in
# readability, and it could also be easier for future changes to miss the return statement and add code
# after it expecting it to be executed.
Style/GuardClause:
Enabled: false
# This is pretty much the same thing as the one above. Inside a loop, it forces you to use next to skip
# iteration rather than using an if block that runs to the end of the loop, and it suffers from the same
# problems as above.
Style/Next:
Enabled: false
Layout/IndentArray:
EnforcedStyle: consistent
# This forces you to change simple if/unless blocks to the conditional form like: `return 2 if badness`.
# Unfortunately there are a number of cases where it makes sense to use the block form even for simple statements,
# and the modifier form can be easy to miss when scanning code.
Style/IfUnlessModifier:
Enabled: false
# This requires you to implement respond_to_missing? anywhere that you implement method_missing, but I think that
# is a lof of a pain.
Style/MethodMissing:
Enabled: false
# This cop forces the use of unless in all negated if statements. Since unless is a source of so many arguments
# and there seems to be no purpose in enforcing its use, disable it.
Style/NegatedIf:
Enabled: false
# This will force you to use methods like .positive? and .zero? rather than > 0 and == 0. But why?
Style/NumericPredicate:
Enabled: false
# This one enforces that functions with names like has_value? be renamed to value?. There are many cases where
# doing so would make the code more difficult to parse.
Style/PredicateName:
Enabled: false
# By default this will force you to use specific names for arguments for enumerable and other methods,
# which I don't understand even a little bit.
Style/SingleLineBlockParams:
Methods: []
# This rule disallows you from parenthesizing the test in ternary operations, so that:
# (p == 100) ? 'success' : ''
# must be written as:
# p == 100 ? 'success' : ''
# I can't possibly be the only one who finds the latter a bit harder to read, can I?
Style/TernaryParentheses:
Enabled: false
# Allow trivial methods that have ? at the end.
Style/TrivialAccessors:
AllowPredicates: true
# It's ok to make a small array of words without using a %w
Style/WordArray:
MinSize: 5
# Some people really like to put lines at the beginning and end of class bodies, while other people
# really don't. It doesn't really seem to matter.
Layout/EmptyLinesAroundClassBody:
Enabled: false
# This forces you to put a comment like this at the top of every single file:
# frozen_string_literal: true
# In Ruby 3, string literals will be frozen by default, so doing so future-proofs
# the code, but in the meantime it's a huge pain in the ass.
Style/FrozenStringLiteralComment:
Enabled: false
# this forces you to use the lambda keyword rather than -> for multiline lambdas, which seems totally arbitrary
Style/Lambda:
Enabled: false
# Force indentation for milti-line expressions and method calls
Layout/MultilineOperationIndentation:
EnforcedStyle: indented
Layout/MultilineMethodCallIndentation:
EnforcedStyle: indented
# This disallows the use of $1, $2 from regular expressions, which seems to make no sense whatsoever
Style/PerlBackrefs:
Enabled: false
# This enforces that multi-line array literals do not end in a comma. For example:
#
# foo = [
# 1,
# 2
# ]
Style/TrailingCommaInLiteral:
EnforcedStyleForMultiline: no_comma
# Same as above but for method arguments rather than array entries.
Style/TrailingCommaInArguments:
EnforcedStyleForMultiline: no_comma
# This forces you to replace things like: `[1, 2, 3].length == 0` with `[1,2,3].empty?`. The problem is that
# not all things that implement length also implement empty? so you will get errors that cannot be resolved,
# and the cop will encourage you to do things that are incorrect.
Style/ZeroLengthPredicate:
Enabled: false
# Enforce alignment of multi-line assignments to be like this:
# variable = if test
# ...
# end
Lint/EndAlignment:
EnforcedStyleAlignWith: variable
# This cop will require you to replace or prefix method arguments that go unused with underscores. The problem
# is that while seeming to solve no problem this could easily cause issues where someone editing the code to
# begin using the variable forgets to remove the underscore. Also, if you replace the argument with _, then
# information about the meaning of that argument is lost.
Lint/UnusedMethodArgument:
Enabled: false
# Same as above but with block arguments.
Lint/UnusedBlockArgument:
Enabled: false
# This cop forces all rescue blocks to do something with the exception. Sometimes you just have an exception
# you want to rescue but do nothing about.
Lint/HandleExceptions:
Enabled: false