Last active
April 19, 2022 14:19
-
-
Save MrLeebo/da65ed64e17970fcc6cb10439e0a0ced to your computer and use it in GitHub Desktop.
rubocop formatting styles
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# In all examples, the rubocop default is listed first | |
# IndentOneStep: false | |
case owner | |
when 'I' | |
attrs[:user] = @current_user | |
when 'they' | |
attrs[:user] = @it | |
end | |
# IndentOneStep: true | |
case owner | |
when 'I' | |
attrs[:user] = @current_user | |
when 'they' | |
attrs[:user] = @it | |
end |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# This refers to both Layout/ParameterAlignment and Layout/ArgumentAlignment | |
# because I imagine they would be kept consistent | |
# EnforcedStyle: with_first_parameter | |
def foo(bar, | |
baz, | |
fizz, | |
buzz | |
) | |
foo(bar, | |
baz, | |
fizz, | |
buzz) | |
# EnforcedStyle: with_fixed_indentation | |
def foo(bar, | |
baz, | |
fizz, | |
buzz | |
) | |
foo(bar, | |
baz, | |
fizz, | |
buzz) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# EnforcedStyle: no_space | |
def print(content_type="text/csv") | |
# EnforcedStyle: space | |
def print(content_type = "text/csv") |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# EnforcedStyle: require_no_space | |
arr.map{ |a| a + 1 } | |
# EnforcedStyle: require_space | |
arr.map { |a| a + 1 } | |
# EnforcedStyle: no_space + SpaceInsideBlockBraces: require_no_space | |
arr.map{|a| a + 1} |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# EnforcedStyle: require_no_space | |
a = ->(x, y) { x + y } | |
# EnforcedStyle: space | |
a = -> (x, y) { x + y } | |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
# EnforcedStyle: no_space | |
var = "This is the #{no_space} example" | |
# EnforcedStyle: space | |
var = "This is the #{ space } example" |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
If I didn't mention a rule, it's because I am fine with or have no opinion about the proposal. So the remaining list is only the items I had anything to comment about:
Layout/CaseIndentation
I would disable
IndentOneStep
, because when you have it enabled the actual code gets indented TWICE even though logically there is only one level of context added.Layout/ParameterArgumentAlignment
I would go with
with_fixed_indentation
because I think it's weird for the indentation of the args to be based on how long the method name isLayout/SpaceAroundEqualsInParametersDefault
I would keep this
no_space
to make it consistent with how defaults are written in JavaScript.Layout/SpaceBeforeBlockBraces
I think this combined with changing
Layout/SpaceInsideBlockBraces
to add spaces just makes blocks too airy. Half of the snippet becomes whitespace with both rules applied.SpaceInLambdaLiteral
Adding a space here feels inconsistent with how functions are declared in any other context.
So I don't think anonymous functions should be treated differently.
Layout/SpaceInsideStringInterpolation
I prefer no_space because it is more consistent with how string interpolation is written in JavaScript
Style/IfUnlessModifier
I think it is a waste to enable this unless we also enforce a sane line length