|
| 1 | +AllCops: |
| 2 | + TargetRubyVersion: "3.0" |
| 3 | + NewCops: enable |
| 4 | + |
| 5 | +#=============================================================================== |
| 6 | +# Layout |
| 7 | +#=============================================================================== |
| 8 | + |
| 9 | +# We don't need empty lines in methods to separate "return if"s from later code. |
| 10 | +Layout/EmptyLineAfterGuardClause: |
| 11 | + Enabled: false |
| 12 | + |
| 13 | +# Extra whitespace often helps to make code more presentable. |
| 14 | +Layout/ExtraSpacing: |
| 15 | + AllowForAlignment: true |
| 16 | + AllowBeforeTrailingComments: true |
| 17 | + |
| 18 | +# In a hash with multiple values (one per line), prefer the => to be lined up |
| 19 | +# and text to otherwise be left-aligned. |
| 20 | +Layout/HashAlignment: |
| 21 | + EnforcedHashRocketStyle: table |
| 22 | + EnforcedColonStyle: table |
| 23 | + |
| 24 | +# This means hashes and arrays are written the same way, rather than hashes |
| 25 | +# needing to be written like { foo => bar } while arrays are like [foo, bar]. |
| 26 | +Layout/SpaceInsideHashLiteralBraces: |
| 27 | + EnforcedStyle: no_space |
| 28 | + |
| 29 | +#=============================================================================== |
| 30 | +# Lint |
| 31 | +#=============================================================================== |
| 32 | + |
| 33 | +# Some methods and blocks will have unused arguments. That's fine. |
| 34 | +Lint/UnusedBlockArgument: |
| 35 | + Enabled: false |
| 36 | +Lint/UnusedMethodArgument: |
| 37 | + Enabled: false |
| 38 | + |
| 39 | +#=============================================================================== |
| 40 | +# Metrics |
| 41 | +#=============================================================================== |
| 42 | + |
| 43 | +# Yes, Essentials has classes/modules/methods that are too big and complex. |
| 44 | +# That's just how it is. |
| 45 | +Metrics: |
| 46 | + Enabled: false |
| 47 | + |
| 48 | +#=============================================================================== |
| 49 | +# Naming |
| 50 | +#=============================================================================== |
| 51 | + |
| 52 | +# This cop forbids class/module names with underscores in them. Having |
| 53 | +# underscores isn't the end of the world. |
| 54 | +Naming/ClassAndModuleCamelCase: |
| 55 | + Enabled: false |
| 56 | + |
| 57 | +# Script files are given names that look reasonable in the list of script |
| 58 | +# sections in RMXP, and are all numbered. They won't be camel_case. |
| 59 | +Naming/FileName: |
| 60 | + Enabled: false |
| 61 | + |
| 62 | +#=============================================================================== |
| 63 | +# Security |
| 64 | +#=============================================================================== |
| 65 | + |
| 66 | +# Script event conditions and script switches are eval'd, amongst other things. |
| 67 | +Security/Eval: |
| 68 | + Enabled: false |
| 69 | + |
| 70 | +# Plenty of things are loaded via Marshal. |
| 71 | +Security/MarshalLoad: |
| 72 | + Enabled: false |
| 73 | + |
| 74 | +#=============================================================================== |
| 75 | +# Style |
| 76 | +#=============================================================================== |
| 77 | + |
| 78 | +# List the attr_reader/writer/accessor variables however you want. |
| 79 | +Style/AccessorGrouping: |
| 80 | + Enabled: false |
| 81 | + |
| 82 | +# The assign_to_condition style looks awful, indenting loads of lines and |
| 83 | +# increasing the separation between variable and value being assigned to it. |
| 84 | +Style/ConditionalAssignment: |
| 85 | + EnforcedStyle: assign_inside_condition |
| 86 | + |
| 87 | +# Check with yard instead. |
| 88 | +Style/Documentation: |
| 89 | + Enabled: false |
| 90 | + |
| 91 | +# It's a choice between format and sprintf. We already make use of sprintf and |
| 92 | +# the translatable _ISPRINTF, so... |
| 93 | +Style/FormatString: |
| 94 | + EnforcedStyle: sprintf |
| 95 | + |
| 96 | +# String literals are not frozen by default, which makes this comment a |
| 97 | +# pointless bit of boilerplate that we neither need nor want. |
| 98 | +Style/FrozenStringLiteralComment: |
| 99 | + Enabled: false |
| 100 | + |
| 101 | +# RMXP and Essentials use lots of global variables. |
| 102 | +Style/GlobalVars: |
| 103 | + Enabled: false |
| 104 | + |
| 105 | +# Mixing the styles within a hash just looks silly. |
| 106 | +Style/HashSyntax: |
| 107 | + EnforcedStyle: no_mixed_keys |
| 108 | + |
| 109 | +# unless just adds mental gymnastics trying to figure out what it actually |
| 110 | +# means. I much prefer if !something. |
| 111 | +Style/NegatedIf: |
| 112 | + Enabled: false |
| 113 | + |
| 114 | +# .zero?, .positive? and .negative? are more wordy than == 0, > 0 and < 0. They |
| 115 | +# also aren't consistent with other value comparisons, e.g. x > 42. |
| 116 | +Style/NumericPredicate: |
| 117 | + EnforcedStyle: comparison |
| 118 | + |
| 119 | +# Following this just means that calls to an affected method need to know what |
| 120 | +# that method calls its parameters, which is ridiculous. Keep things short and |
| 121 | +# simple. |
| 122 | +Style/OptionalBooleanParameter: |
| 123 | + Enabled: false |
| 124 | + |
| 125 | +# has_key? and has_value? are far more readable than key? and value? |
| 126 | +Style/PreferredHashMethods: |
| 127 | + Enabled: false |
| 128 | + |
| 129 | +# Explicit returns help to show whether a method returns a value. |
| 130 | +Style/RedundantReturn: |
| 131 | + Enabled: false |
| 132 | + |
| 133 | +# Enforcing the names of variables? To single letter ones? Just no. |
| 134 | +Style/SingleLineBlockParams: |
| 135 | + Enabled: false |
| 136 | + |
| 137 | +# Single line methods use up less space, and they're easier to list next to each |
| 138 | +# other and see that they behave similarly. |
| 139 | +Style/SingleLineMethods: |
| 140 | + Enabled: false |
| 141 | + |
| 142 | +# Single quotes being faster is hardly measurable and only affects parse time. |
| 143 | +# Enforcing double quotes reduces the times where you need to change them |
| 144 | +# when introducing an interpolation or an apostrophe. Use single quotes only if |
| 145 | +# their semantics are needed. |
| 146 | +Style/StringLiterals: |
| 147 | + EnforcedStyle: double_quotes |
| 148 | + |
| 149 | +# This cop requires arrays of symbols/text to be written like %i[a b c]. We |
| 150 | +# don't need that nonsense. ["a", "b", "c"] is clearer and introduces no |
| 151 | +# additional syntax to confuse people. |
| 152 | +Style/SymbolArray: |
| 153 | + EnforcedStyle: brackets |
| 154 | +Style/WordArray: |
| 155 | + EnforcedStyle: brackets |
| 156 | + |
| 157 | +# Patentheses around the condition in a ternary operator helps to differentiate |
| 158 | +# it from the true/false results. |
| 159 | +Style/TernaryParentheses: |
| 160 | + EnforcedStyle: require_parentheses |
0 commit comments