Style/Blocks poorly named and/or doesn't support other styles #1600
Comments
|
Related: rubocop/ruby-style-guide#162 |
|
thanks for the linkage. good commentary over there. |
mudge
pushed a commit
to clowdge/rubocop
that referenced
this issue
Mar 21, 2015
* rubocop#1600 * rubocop/ruby-style-guide#162 * http://devblog.avdi.org/2011/07/26/the-procedurefunction-block-convention-in-ruby/ Add a configuration option to the Style/Blocks cop to permit two styles: * multiline (the current default); * weirich (the semantic rule as described in the links above). With Weirich style enabled, this allows multi-line blocks with braces if the block is considered "functional". The current implementation checks whether the return value of a block is used to classify it as "functional". It performs the following checks: 1. Is the return value of the block being assigned? 2. Is the return value of the block sent a message? 3. Is the return value of the block the last thing in its scope? This should cover the following Weirich-style use cases: # 1 foo = map { |x| x * 2 } # 2 map { |x| x * 2 }.inspect # 3 block do foo map { |x| x * 2 } end # 3 puts map { |x| x * 2 } Add offenses if the return value of a block is used but do...end is used instead of the intention-revealing {...}. Conversely, if the return value of a block is not used, add an offense if {...} is used instead of do...end. Add a configurable whitelist of methods that use the return value of their block without being obvious to the caller. This permits use cases such as let or subject in RSpec. As DSLs often use do...end (e.g. RSpec.describe), do not add an offense if a block uses do...end even though it could potentially be the return value of its outer scope, e.g. RSpec.describe Foo do it 'blah' do # ... end end
mudge
pushed a commit
to clowdge/rubocop
that referenced
this issue
Mar 21, 2015
* rubocop#1600 * rubocop/ruby-style-guide#162 * http://devblog.avdi.org/2011/07/26/the-procedurefunction-block-convention-in-ruby/ Add a configuration option to the Style/Blocks cop to permit two styles: * multiline (the current default); * weirich (the semantic rule as described in the links above). With Weirich style enabled, this allows multi-line blocks with braces if the block is considered "functional". The current implementation checks whether the return value of a block is used to classify it as "functional". It performs the following checks: 1. Is the return value of the block being assigned? 2. Is the return value of the block sent a message? 3. Is the return value of the block the last thing in its scope? This should cover the following Weirich-style use cases: # 1 foo = map { |x| x * 2 } # 2 map { |x| x * 2 }.inspect # 3 block do foo map { |x| x * 2 } end # 3 puts map { |x| x * 2 } Add offenses if the return value of a block is used but do...end is used instead of the intention-revealing {...}. Conversely, if the return value of a block is not used, add an offense if {...} is used instead of do...end. Add a configurable whitelist of methods that use the return value of their block without being obvious to the caller. This permits use cases such as let or subject in RSpec. As DSLs often use do...end (e.g. RSpec.describe), do not add an offense if a block uses do...end even though it could potentially be the return value of its outer scope, e.g. RSpec.describe Foo do it 'blah' do # ... end end
mudge
pushed a commit
to clowdge/rubocop
that referenced
this issue
Mar 22, 2015
* rubocop#1600 * rubocop/ruby-style-guide#162 * http://devblog.avdi.org/2011/07/26/the-procedurefunction-block-convention-in-ruby/ Add a configuration option to the Style/Blocks cop to permit two styles: * multiline (the current default); * weirich (the semantic rule as described in the links above). With Weirich style enabled, this allows multi-line blocks with braces if the block is considered "functional". The current implementation checks whether the return value of a block is used to classify it as "functional". It performs the following checks: 1. Is the return value of the block being assigned? 2. Is the return value of the block sent a message? 3. Is the return value of the block the last thing in its scope? This should cover the following Weirich-style use cases: # 1 foo = map { |x| x * 2 } # 2 map { |x| x * 2 }.inspect # 3 block do foo map { |x| x * 2 } end # 3 puts map { |x| x * 2 } Add offenses if the return value of a block is used but do...end is used instead of the intention-revealing {...}. Conversely, if the return value of a block is not used, add an offense if {...} is used instead of do...end. Add a configurable whitelist of methods that use the return value of their block without being obvious to the caller. This permits use cases such as let or subject in RSpec. As DSLs often use do...end (e.g. RSpec.describe), do not add an offense if a block uses do...end even though it could potentially be the return value of its outer scope, e.g. RSpec.describe Foo do it 'blah' do # ... end end
mudge
pushed a commit
to clowdge/rubocop
that referenced
this issue
Mar 22, 2015
* rubocop#1600 * rubocop/ruby-style-guide#162 * http://devblog.avdi.org/2011/07/26/the-procedurefunction-block-convention-in-ruby/ Add a configuration option to the Style/Blocks cop to permit two styles: * multiline (the current default); * weirich (the semantic rule as described in the links above). With Weirich style enabled, this allows multi-line blocks with braces if the block is considered "functional". The current implementation checks whether the return value of a block is used to classify it as "functional". It performs the following checks: 1. Is the return value of the block being assigned? 2. Is the return value of the block sent a message? 3. Is the return value of the block the last thing in its scope? This should cover the following Weirich-style use cases: # 1 foo = map { |x| x * 2 } # 2 map { |x| x * 2 }.inspect # 3 block do foo map { |x| x * 2 } end # 3 puts map { |x| x * 2 } Add offenses if the return value of a block is used but do...end is used instead of the intention-revealing {...}. Conversely, if the return value of a block is not used, add an offense if {...} is used instead of do...end. Add a configurable whitelist of methods that use the return value of their block without being obvious to the caller. This permits use cases such as let or subject in RSpec. The same whitelist can be used to permit methods that don't use the return value of their block despite being used in assignment such as tap or Active Record's create and new. As DSLs often use do...end (e.g. RSpec.describe), do not add an offense if a block uses do...end even though it could potentially be the return value of its outer scope, e.g. RSpec.describe Foo do it 'blah' do # ... end end
mudge
pushed a commit
to clowdge/rubocop
that referenced
this issue
Mar 23, 2015
* rubocop#1600 * rubocop/ruby-style-guide#162 * http://devblog.avdi.org/2011/07/26/the-procedurefunction-block-convention-in-ruby/ Add a configuration option to the Style/Blocks cop to permit two styles: * multiline (the current default); * weirich (the semantic rule as described in the links above). With Weirich style enabled, this allows multi-line blocks with braces if the block is considered "functional". The current implementation checks whether the return value of a block is used to classify it as "functional". It performs the following checks: 1. Is the return value of the block being assigned? 2. Is the return value of the block sent a message? 3. Is the return value of the block the last thing in its scope? This should cover the following Weirich-style use cases: # 1 foo = map { |x| x * 2 } # 2 map { |x| x * 2 }.inspect # 3 block do foo map { |x| x * 2 } end # 3 puts map { |x| x * 2 } Add offenses if the return value of a block is used but do...end is used instead of the intention-revealing {...}. Conversely, if the return value of a block is not used, add an offense if {...} is used instead of do...end. Add a configurable whitelist of methods that use the return value of their block without being obvious to the caller. This permits use cases such as let or subject in RSpec. The same whitelist can be used to permit methods that don't use the return value of their block despite being used in assignment such as tap or Active Record's create and new. As DSLs often use do...end (e.g. RSpec.describe), do not add an offense if a block uses do...end even though it could potentially be the return value of its outer scope, e.g. RSpec.describe Foo do it 'blah' do # ... end end
mudge
pushed a commit
to clowdge/rubocop
that referenced
this issue
Mar 29, 2015
* rubocop#1600 * rubocop/ruby-style-guide#162 * http://devblog.avdi.org/2011/07/26/the-procedurefunction-block-convention-in-ruby/ Add a configuration option to the `Style/Blocks` cop to permit two styles: * `multiline` (the current default); * `weirich` (the semantic rule as described in the links above). With Weirich style enabled, this allows multi-line blocks with braces if the block is considered "functional". The current implementation checks whether the return value of a block is used to classify it as "functional". It performs the following checks: 1. Is the return value of the block being assigned? 2. Is the return value of the block sent a message? 3. Is the return value of the block the last thing in its scope? This should cover the following Weirich-style use cases: # 1 foo = map { |x| x * 2 } # 2 map { |x| x * 2 }.inspect # 3 block do foo map { |x| x * 2 } end # 3 puts map { |x| x * 2 } Add offenses if the return value of a block is used but `do`...`end` is used instead of the intention-revealing `{`...`}`. Conversely, if the return value of a block is not used, add an offense if `{`...`}` is used instead of `do`...`end`. As there are some methods that are functional or procedural but cannot be categorised as such from their usage alone, add configurable lists to permit methods such as `RSpec::Core::ExampleGroup.let` which is functional but appears procedural and `tap` which is procedural but appears functional. For methods which can be both functional and procedural (such as `lambda`) and cannot be categorised by usage, add a configurable list of ignored methods. As DSLs often use `do`...`end` (e.g. `RSpec.describe`), do not add an offense if a block uses `do`...`end` even though it could potentially be the return value of its outer scope, e.g. RSpec.describe Foo do it 'blah' do # ... end end
mudge
pushed a commit
to clowdge/rubocop
that referenced
this issue
Mar 29, 2015
* rubocop#1600 * rubocop/ruby-style-guide#162 * http://devblog.avdi.org/2011/07/26/the-procedurefunction-block-convention-in-ruby/ Add a configuration option to the `Style/Blocks` cop to permit two styles: * `multiline` (the current default); * `weirich` (the semantic rule as described in the links above). With Weirich style enabled, this allows multi-line blocks with braces if the block is considered "functional". The current implementation checks whether the return value of a block is used to classify it as "functional". It performs the following checks: 1. Is the return value of the block being assigned? 2. Is the return value of the block sent a message? 3. Is the return value of the block the last thing in its scope? This should cover the following Weirich-style use cases: # 1 foo = map { |x| x * 2 } # 2 map { |x| x * 2 }.inspect # 3 block do foo map { |x| x * 2 } end # 3 puts map { |x| x * 2 } Add offenses if the return value of a block is used but `do`...`end` is used instead of the intention-revealing `{`...`}`. Conversely, if the return value of a block is not used, add an offense if `{`...`}` is used instead of `do`...`end`. As there are some methods that are functional or procedural but cannot be categorised as such from their usage alone, add configurable lists to permit methods such as `RSpec::Core::ExampleGroup.let` which is functional but appears procedural and `tap` which is procedural but appears functional. For methods which can be both functional and procedural (such as `lambda`) and cannot be categorised by usage, add a configurable list of ignored methods. As DSLs often use `do`...`end` (e.g. `RSpec.describe`), do not add an offense if a block uses `do`...`end` even though it could potentially be the return value of its outer scope, e.g. RSpec.describe Foo do it 'blah' do # ... end end
mudge
pushed a commit
to clowdge/rubocop
that referenced
this issue
Mar 29, 2015
* rubocop#1600 * rubocop/ruby-style-guide#162 * http://devblog.avdi.org/2011/07/26/the-procedurefunction-block-convention-in-ruby/ Add a configuration option to the `Style/Blocks` cop to permit two styles: * `multiline` (the current default); * `weirich` (the semantic rule as described in the links above). With Weirich style enabled, this allows multi-line blocks with braces if the block is considered "functional". The current implementation checks whether the return value of a block is used to classify it as "functional". It performs the following checks: 1. Is the return value of the block being assigned? 2. Is the return value of the block sent a message? 3. Is the return value of the block the last thing in its scope? This should cover the following Weirich-style use cases: # 1 foo = map { |x| x * 2 } # 2 map { |x| x * 2 }.inspect # 3 block do foo map { |x| x * 2 } end # 3 puts map { |x| x * 2 } Add offenses if the return value of a block is used but `do`...`end` is used instead of the intention-revealing `{`...`}`. Conversely, if the return value of a block is not used, add an offense if `{`...`}` is used instead of `do`...`end`. As there are some methods that are functional or procedural but cannot be categorised as such from their usage alone, add configurable lists to permit methods such as `RSpec::Core::ExampleGroup.let` which is functional but appears procedural and `tap` which is procedural but appears functional. For methods which can be both functional and procedural (such as `lambda`) and cannot be categorised by usage, add a configurable list of ignored methods. As DSLs often use `do`...`end` (e.g. `RSpec.describe`), do not add an offense if a block uses `do`...`end` even though it could potentially be the return value of its outer scope, e.g. RSpec.describe Foo do it 'blah' do # ... end end
mudge
pushed a commit
to clowdge/rubocop
that referenced
this issue
Apr 2, 2015
* rubocop#1600 * rubocop/ruby-style-guide#162 * http://devblog.avdi.org/2011/07/26/the-procedurefunction-block-convention-in-ruby/ Add a configuration option to the `Style/Blocks` cop to permit two styles: * `multiline` (the current default); * `weirich` (the semantic rule as described in the links above). With Weirich style enabled, this allows multi-line blocks with braces if the block is considered "functional". The current implementation checks whether the return value of a block is used to classify it as "functional". It performs the following checks: 1. Is the return value of the block being assigned? 2. Is the return value of the block sent a message? 3. Is the return value of the block the last thing in its scope? This should cover the following Weirich-style use cases: # 1 foo = map { |x| x * 2 } # 2 map { |x| x * 2 }.inspect # 3 block do foo map { |x| x * 2 } end # 3 puts map { |x| x * 2 } Add offenses if the return value of a block is used but `do`...`end` is used instead of the intention-revealing `{`...`}`. Conversely, if the return value of a block is not used, add an offense if `{`...`}` is used instead of `do`...`end`. As there are some methods that are functional or procedural but cannot be categorised as such from their usage alone, add configurable lists to permit methods such as `RSpec::Core::ExampleGroup.let` which is functional but appears procedural and `tap` which is procedural but appears functional. For methods which can be both functional and procedural (such as `lambda`) and cannot be categorised by usage, add a configurable list of ignored methods. As DSLs often use `do`...`end` (e.g. `RSpec.describe`), do not add an offense if a block uses `do`...`end` even though it could potentially be the return value of its outer scope, e.g. RSpec.describe Foo do it 'blah' do # ... end end
mudge
pushed a commit
to clowdge/rubocop
that referenced
this issue
Apr 5, 2015
* rubocop#1600 * rubocop/ruby-style-guide#162 * http://devblog.avdi.org/2011/07/26/the-procedurefunction-block-convention-in-ruby/ Add a configuration option to the `Style/Blocks` cop to permit two styles: * `line_count_based` (the current default); * `semantic` (the semantic rule as described in the links above). With semantic style enabled, this allows multi-line blocks with braces if the block is considered "functional". The current implementation checks whether the return value of a block is used to classify it as "functional". It performs the following checks: 1. Is the return value of the block being assigned? 2. Is the return value of the block sent a message? 3. Is the return value of the block the last thing in its scope? This should cover the following semantic style use cases: # 1 foo = map { |x| x * 2 } # 2 map { |x| x * 2 }.inspect # 3 block do foo map { |x| x * 2 } end # 3 puts map { |x| x * 2 } Add offenses if the return value of a block is used but `do`...`end` is used instead of the intention-revealing `{`...`}`. Conversely, if the return value of a block is not used, add an offense if `{`...`}` is used instead of `do`...`end`. As there are some methods that are functional or procedural but cannot be categorised as such from their usage alone, add configurable lists to permit methods such as `RSpec::Core::ExampleGroup.let` which is functional but appears procedural and `tap` which is procedural but appears functional. For methods which can be both functional and procedural (such as `lambda`) and cannot be categorised by usage, add a configurable list of ignored methods. As DSLs often use `do`...`end` (e.g. `RSpec.describe`), do not add an offense if a block uses `do`...`end` even though it could potentially be the return value of its outer scope, e.g. RSpec.describe Foo do it 'blah' do # ... end end
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Style/Blocks is about using
{}for single-line blocks anddo endfor multi-line blocks. Either it should be renamed to be specifically about that, or it would be nice if it were expanded to be smarter about other styles. I'm thinking specifically about the Weirich method.The text was updated successfully, but these errors were encountered: