I would personally oppose trusting any configuration of Rubocop for example
code in Ruby or in Ruby included in the distribution. The default Rubocop
configuration has almost no connection to how I use Ruby (and while my
style has evolved over the last fifteen years, there”Ēs a lot which I picked
up and still use”½and because I”Ēm the boss, enforce in my company”Ēs use of
Rubocop); I find that I disable or adjust around  of the rules, and I
especially disable the complexity metrics.

Unless and until there is a clear *single* Ruby style (as appears to be
happening in the Elixir community with `mix format`) with a built-in Ruby
formatter, this is not even remotely a good idea.

-a

On Fri, Nov 17, 2017 at 8:13 AM, <anamma06 / gmail.com> wrote:

> Issue #14112 has been updated by ana06 (Ana Maria Martinez Gomez).
>
>
> @shevegen
>
> > Ruby inherited the Perl philosophy of having more than one way to do the
> same thing.
> I inherited that philosophy from Larry Wall, who is my hero actually. I
> want to make
> Ruby users free. I want to give them the freedom to choose. People are
> different.
> People choose different criteria. But if there is a better way among many
> alternatives,
> I want to encourage that way by making it comfortable.
>
> @matz and what happens with the people reading the code? They may be
> different to the people writing the code.
>
> Ruby claims to be natural to read and focus on simplicity and
> productivity. Do you really think that mixing in the code several ways to
> write the same encourage this principles?
>
> > In particular this is my biggest problem with the style guide that is
> used by rubocop.
> Rubocop enforces ONE particular style (by default; you can change this of
> course, but
> I refer to the "main style guide" here) - but the ruby parser allows you
> to have a lot
> more freedom in how YOU want to write ruby code. Yes, other people may not
> always write
> the "cleanest" code and what not, but you have the same situation applied
> in reverse.
> Other people may dislike your code too. This is what comes with diversity
> - both
> advantages and disadvantages.
>
> Rubocop is community maintained. I think that the fact that many Ruby
> developers are using Rubocop should also be taken into account.
>
> > I give you an example. Take @@foo variables. I do not like them; I do
> not hate them
> either. More importantly though, I do not need them - and so I do not have
> to use
> them. The same applies to many other concepts in ruby, be it the lambda
> operator
> which I do not use, or the new hash notation, which I actually use
> sometimes (since
> it can lead to more concise code), or the lonely person operator, which I
> also do
> not use (but notice how it was added; a ruby hacker had a need and use
> case, matz
> agreed with the use case and the operator was added, so ruby hackers also
> have
> some ways to influence the evolution of ruby, which is good, even if I
> personally
> don't use the person-staring-at-a-dot operator). I can happily use ruby
> without
> HAVING to use everything. It also does not bother me greatly either - I
> can just
> focus on code that I write, and ignore the rest. :)
>
> But you may find things you don't use in other people code, which you may
> have to work with.
>
>
>
> ----------------------------------------
> Feature #14112: Follow style conventions for Ruby code
> https://bugs.ruby-lang.org/issues/14112#change-67840
>
> * Author: ana06 (Ana Maria Martinez Gomez)
> * Status: Open
> * Priority: Normal
> * Assignee:
> * Target version:
> ----------------------------------------
> The Ruby code in the documentation and in the tests is currently not
> following any style rules, which leads to long style discussions in PRs as
> well as making the code more complicate to read and understand.
>
> I would really like that Ruby documentation follows [Ruby Style Guide](
> https://github.com/bbatsov/ruby-style-guide) or equivalently [Rubocop
> rules](https://github.com/bbatsov/rubocop) as they are driven by the Ruby
> community and it would be consistent and helpful when developing that Ruby
> documentation follows it as well.
>
> This way we wouldn't need to discuss anything about style in PRs. And when
> copying code from the documentation you don't have to modify it afterwards.
>
>
>
> --
> https://bugs.ruby-lang.org/
>
> Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
> <http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>
>



-- 
Austin Ziegler  halostatue / gmail.com  austin / halostatue.ca
http://www.halostatue.ca/  http://twitter.com/halostatue
(supressed text/html)
Unsubscribe: <mailto:ruby-core-request / ruby-lang.org?subject=unsubscribe>
<http://lists.ruby-lang.org/cgi-bin/mailman/options/ruby-core>