Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

trailing commas should be encouraged in multiline literals #273

Open
tamird opened this issue Jan 23, 2014 · 52 comments

Comments

Projects
None yet
@tamird
Copy link

commented Jan 23, 2014

Title says it all. Please discuss.

@bbatsov

This comment has been minimized.

Copy link
Collaborator

commented Jan 23, 2014

I'm against such a change. There's not a single strong argument to support this style:

  • Simpler VCS diffs

We shouldn't add superfluous characters to work around tool limitations.

  • You won't forget to add the preceding comma when adding a new element

    Well, you'll get a syntax error otherwise, so you're covered.

  • The style is popular in the Ruby community.

There's no data to back such claim and based on my observations of Ruby projects it's unlikely that someone will gather it. The style's popular in the Python community for sure, but it's rarely used in Ruby projects.

@tamird

This comment has been minimized.

Copy link
Author

commented Jan 23, 2014

I'm against such a change. There's not a single strong argument to support this style:

This is itself a non-reason. Are there any arguments against this style?

  • Simpler VCS diffs

We shouldn't add superfluous characters to work around tool limitations.

Actually, the whole point of a style guide is to work around tool limitations. If our canonical representation of code was not text, we could completely disregard style such as whitespace, hash rockets, etc. and just have editors render the code in our preferred style. Given this, I think simpler VCS diffs are totally a legit argument for this style.

You won't forget to add the preceding comma when adding a new element

Well, you'll get a syntax error otherwise, so you're covered.

Sure, I agree. Again, this is not a reason against.

The style is popular in the Ruby community.

There's no data to back such claim and based on my observations of Ruby projects it's unlikely that someone will gather it. The style's popular in the Python community for sure, but it's rarely used in Ruby projects.

You're making exactly the assertion that you challenge. There is no conclusive data either way, so this point is not valid in either direction.

For me, the biggest win is the VCS thing, and I don't see why that's not a legitimate thing to consider. What do you think?

@jkingdon

This comment has been minimized.

Copy link

commented Jan 23, 2014

At the risk of stating the obvious, we're talking about things like:

[
  534,
  78,
]

{
  a: 'foobar',
  b: 'foobaz',
}

and the question is whether to have a comma after 78 or foobaz, right? I'd be in the pro-comma camp, partly for VCS but also line-oriented commands in text editors. As for what is more common in the ruby community, I don't know about that and it could be a legitimate concern (I am, for the most part, a fan of a style guide which follows, rather than leads, existing practice).

@JackDanger

This comment has been minimized.

Copy link

commented Jan 23, 2014

I got out of the habit of trailing commas when it would break my JS in IE6. I love that we now live in a world where that's not a problem. I'd be in favor of ensuring a trailing comma exists.

@edruder

This comment has been minimized.

Copy link

commented Jan 23, 2014

I didn't see this benefit mentioned: it's not uncommon to move elements in arrays and hashes around while refactoring/changing logic--when there's a trailing comma, this movement doesn't involve an "add a comma to the former last element & remove a comma from the new last element" step.

@bbatsov

This comment has been minimized.

Copy link
Collaborator

commented Jan 23, 2014

Commas are meant to be used as separators, using them in any other way is kind of against their semantics. I'm saying this in a general sense. Since code layout is mostly for the benefit of humans we should optimize it for human minds - personally, when I see a comma, I expect to see another item following it. Consider this:

a = [1, 2, 3]

a = [1, 2, 3,] # wat? why's there nothing after the comma?

a = [
 1, # I was hoping for more items after this one :-)
]

The second expression would often be interpreted by a human mind as incomplete. @tamird Whitespace, newlines, etc serve exactly the same purpose - making it friendly for our brains.

@indspenceable

This comment has been minimized.

Copy link

commented Jan 23, 2014

Commas aren't strictly seperators in ruby; the fact that

[
  :hello,
  :world,
]

is valid should prove that.

@bbatsov

This comment has been minimized.

Copy link
Collaborator

commented Jan 23, 2014

@indspenceable To quote myself - I'm saying this in a general sense.. I'm quite aware how commas are interpreted by Ruby's parser(s). You can also write code like this, but is it a good idea?

x = 5,
y = 6
# => [5, 6]

The result would likely surprise some people. :-)

@xaviershay

This comment has been minimized.

Copy link

commented Jan 23, 2014

[ "I for one"
, "would support"
, "haskell style leading commas"
]
@tamird

This comment has been minimized.

Copy link
Author

commented Jan 23, 2014

@bbatsov but we're not talking about the general case -- this discussion is framed as "...multiline literals". Agree?

@sandersch

This comment has been minimized.

Copy link

commented Jan 23, 2014

I'm fully in the trailing commas camp. Using them provides cleaner diffs and the easier ability to reorder elements. I agree they look bizarre in a single line literal, but they look fine to me in multiline literals which as the case discussed here.

I see multiple benefits and not a single real drawback.

@tamird

This comment has been minimized.

Copy link
Author

commented Feb 6, 2014

ping @bbatsov can we get this change made?

@nixpulvis

This comment has been minimized.

Copy link

commented Feb 10, 2014

@tamird

Actually, the whole point of a style guide is to work around tool limitations

No no no, the point of a style guide is to provide guidance on how to write code when there is more than one way to write the same thing.

@JackDanger

This comment has been minimized.

Copy link

commented Feb 10, 2014

No no no, the point of a style guide is to provide guidance on how to write code when there is more than one way to write the same thing.

Those are very similar things. The reason a syntax checker in an editor won't make this change automatically is because trailing commas or missing trailing commas are both syntactically valid ways to write the same thing. If the language were more compact then the tools could be, too.

@lamont-granquist

This comment has been minimized.

Copy link

commented Feb 16, 2014

This rule is horrible.

I'd like all the minutes back of my life that I've spent dealing with JSON enforcing this rule and half the time I rearrange a block of JSON it fails to parse and I wind up either need to whack off the trailing comma and/or track down where I copied the previous trailing comma-less entry. We are not writing literature here, we are trying to efficiently write software. This rule gets in the way. Breaks the ability to manipulate text purely as lines. And then there's always the additional churn in diffs.

@steveklabnik

This comment has been minimized.

Copy link

commented Feb 19, 2014

I feel very, very strongly that trailing commas are better. Cleaner diffs, consistency with other lines...

@nixpulvis

This comment has been minimized.

Copy link

commented Feb 19, 2014

I used to argue the same points, however I've had this conversation enough times now to realize that diffs are a really weak argument for coding a specific way.

array = [1, 2, 3, 4, 5]
array = [
  1,
  2,
  3,
  4,
  5
]

never = [1, 2, 3, 4, 5,]

The comma is logically a separator between elements of the array/hash. Separating nothing implies subtly that there is something after the last element.

@tamird

This comment has been minimized.

Copy link
Author

commented Feb 19, 2014

@nixpulvis again, this discussion is about multiline literals.

@nixpulvis

This comment has been minimized.

Copy link

commented Feb 19, 2014

That's my point, they are conceptually the same thing. Updated for clarity.

@jamesotron

This comment has been minimized.

Copy link

commented Feb 19, 2014

I am in favour of this change, but only if the final comma is replaced with U+1F4A9, otherwise known as PILE OF POO. 💩

@fuadsaud

This comment has been minimized.

Copy link
Contributor

commented Feb 19, 2014

@jamesotron omg, is that even possible

@lamont-granquist

This comment has been minimized.

Copy link

commented Feb 20, 2014

@nixpulvis the diffs are a weak argument. the mistakes made when manipulating multiline structures is the stronger argument. the default that rubocop has now actively encourages syntax mistakes.

@tamird tamird referenced this issue Feb 20, 2014

Closed

Trailing comma #290

@bbatsov

This comment has been minimized.

Copy link
Collaborator

commented Feb 21, 2014

@lamont-granquist That's not correct at all. If you're using editor integration for RuboCop (or even the basic MRI linter) you'll get immediate feedback for such trivial syntax errors. That's why I don't place much value on this argument.

@gnapse

This comment has been minimized.

Copy link
Contributor

commented Mar 10, 2014

Totally agree 100% on recommending trailing commas in multi-line arrays and hashes. Here's my thought process around it.

I didn't see this benefit mentioned: it's not uncommon to move elements in arrays and hashes around while refactoring/changing logic--when there's a trailing comma, this movement doesn't involve an "add a comma to the former last element & remove a comma from the new last element" step. -- @edruder

First, the VCS argument, plus this other one quoted above, are great reasons for supporting this. I always type the trailing comma on multi-line arrays and hashes.

To further support the VCS argument, allow me to mention git blame. You probably all know what it is. Without trailing commas, lines could end-up being blamed to someone who did not actually authored it. Just because you added a comma in order to add more items to the array or hash, does not make you the author of that line.

git blame has even the ability to ignore whitespace changes and line movements, so when you indent a line, or you move code around the file, blame can still be put on the actual author. But detecting trailing commas is a change too strong for git to accommodate to it, because it could have different meanings in different languages. It turns out in Ruby and several other languages, it was precisely allowed so that we could write code leading to cleaner diffs, so why not recommend it?

@mvz

This comment has been minimized.

Copy link

commented Apr 3, 2014

There are many other reasons for accidentally getting blamed for a line. The solution is not code formatting but better use of tools. Once you have blamed a line on someone, you should always look at the commit in question to see what changed. The result may be that you need to dig deeper. Vim's git plugin 'fugitive' can do this, for example.

@gnapse

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2014

Ok agreed. I only said it was another reason for it the trailin commas in
multiline arrays. But what are really the reasons against it? I haven't
heard any really good reason except personal preference and bias against
it. The style guide should at least not discourage it's use, but say it's
ok both ways, IMO.

On Thursday, April 3, 2014, Matijs van Zuijlen notifications@github.com
wrote:

There are many other reasons for accidentally getting blamed for a line.
The solution is not code formatting but better use of tools. Once you have
blamed a line on someone, you should always look at the commit in question
to see what changed. The result may be that you need to dig deeper. Vim's
git plugin 'fugitive' can do this, for example.

Reply to this email directly or view it on GitHubhttps://github.com//issues/273#issuecomment-39441156
.

Ernesto
about.me/gnapse
@gnapse https://twitter.com/gnapse

@gnapse

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2014

We shouldn't add superfluous characters to work around tool limitations.

Semicolons are used all the time in various programming languages due to limitations in grammar parsers. And I'm sure there are other examples of "superfluous" characters being used in different contexts to work around tool limitations.

Also, under that logic, we shouldn't bother on trimming trailing whitespace on our source code. They are invisible anyway, unless you configure your editor to show them, and the only real reason to avoid them is to have cleaner diffs. Oh, wait! But that reason is not good enough, because we also discourage using trailing commas in multi-line arrays in spite of having the advantage of giving cleaner diffs too.

So recommending against trailing whitespace is inconsistent with discouraging trailing commas. Plus trailing commas have the added benefit mentioned by @edruder above, when refactoring/reordering a multi-line array literal. It's not just the cleaner diff argument.

@nixpulvis

This comment has been minimized.

Copy link

commented Apr 3, 2014

Notice how ruby doesn't have semicolon requirements. Trailing whitespace is superfluous just like trailing comas.

I think the trend is that we should be avoiding superfluous characters. Your logic that !Trailing Whitespace => Trailing Commas seems off.

@gnapse

This comment has been minimized.

Copy link
Contributor

commented Apr 3, 2014

I didn't say Ruby has semicolons, but thanks for pointing that out because I had not notice it until now ;)

If the trend is avoiding superfluous characters, then we should be avoiding parenthesis around method arguments, both in method definitions and method calls. What makes a character superfluous exactly?

Now seriously, I agree that parenthesis in the case mentioned above are not superfluous because they make things more readable. Well, I happen to think that the trailing comma in the case being discussed here makes things more readable too. So for me it's not superfluous. Superfluous is in many cases, a matter of opinion, not a fact written in stone.

And again, trailing whitespace does not make anything more or less readable. The only real reason everyone agrees to discourage it, in nearly every known programming language, is because it gives cleaner diffs.

But as in matters of religion, I think it'll be too hard to convince anyone here so vehemently opposing this change. We're not asking to encourage them, but merely to present it as an acceptable alternative, and perhaps mentioning the advantage of cleaner diffs and easier reordering of lines. It's not just a whim!

@binaryphile

This comment has been minimized.

Copy link

commented Dec 2, 2015

To be fair, the rationale for the trailing newline at the end of a file is precisely the same as that for the trailing comma in lists. It is to ease automation by providing a uniform syntax for all elements, allowing for uniform manipulation of the elements (lines or list elements), whether by humans or programs.

I think the likely saving virtue of the newline that allows it into the recommended practices of the style guide is that it is invisible and hence doesn't affect readability. Nevertheless, it was provided for a reason, and it should at least be acknowledged that the trailing comma has its purpose as well. It seems arbitrary to go so far as to deem it "bad" form. I think the guide is venturing into territory that isn't representative of any sort of community consensus here.

Reasonable people can certainly disagree on this one.

@JackDanger

This comment has been minimized.

Copy link

commented Dec 2, 2015

@bbatsov Your example of why trailing commas are unwelcome involved single line arrays with a trailing comma:

a = [1, 2, 3, ]

And a list with a small (one) number of elements:

a = [
 1,
]

I think we're in agreement that in a single-line array literal the trailing comma looks bad. So nobody wants the first form.
The second one is extremely rare, however. I almost never see multi-line array literals for just one element. More likely it's this:

a = [
 :dog,
 :cat,
 :bird,
]

Which is a very popular form and having a trailing comma on the last element makes reorganizing the list much cleaner.
How about we require trailing commas only for lists that use multiple lines and have more than one element?

@jszmajda

This comment has been minimized.

Copy link

commented Feb 26, 2016

My concern is about cognitive load. As programmers we work hard to minimize the context we need to have in our brains when working through problems. We're human and the less we have to consider when working the better our outcomes will be.

It's true that collapsing multiline literals into a single line will create problems, however that use case is rare, as is the multiline literal with a single value. The vast majority of uses are for stable literals with many values.

The issue then is how much context do you have to have when reviewing a diff? A single comma addition, while miniscule, is one more line of context that must be reviewed.

Please optimize efficiency and minimize cognitive load: prefer trailing commas on multiline literals, or at the very least don't prefer the lack thereof.

petems added a commit to petems/modulesync_config that referenced this issue Mar 1, 2016

Updates to ignore
Raise an error if users don't leave trailing commas. Nicer for the coder who comes after you.

This might be a bit controversial, it's still kinda argued in the Ruby community: rubocop-hq/ruby-style-guide#273

petems added a commit to petems/modulesync_config that referenced this issue Mar 1, 2016

Change to get user to leave trailing comma
Raise an error if users don't leave trailing commas. Nicer for the coder who comes after you.
This might be a bit controversial, it's still kinda argued in the Ruby community: rubocop-hq/ruby-style-guide#273

petems added a commit to petems/modulesync_config that referenced this issue Mar 1, 2016

Change to get user to leave trailing comma
Raise an error if users don't leave trailing commas. Nicer for the coder who comes after you.
This might be a bit controversial, it's still kinda argued in the Ruby community: rubocop-hq/ruby-style-guide#273
@kolorahl

This comment has been minimized.

Copy link

commented Aug 10, 2016

I'm also for trailing commas, but my two cents on why follows reasoning surrounding functional languages.

In a functional language (such as Elixir or Erlang), a list can generally be thought of as one head element and a list of trailing elements. In the case of a single item in a list you could represent it as such:

iex(1)> [ 2 | [] ]
[2]

This is actually quite useful because recursion is used heavily for processing lists and you can perform pattern-matching on the function head to stop further processing once you hit an empty list.

def sum([], acc) do
  acc
end
def sum([x | xs], acc) do
  sum(xs, acc + x)
end

When you hit the final element of a list in the above sum/2 function, xs will be an empty list; one head element (the final element) plus a tail represented by an empty list.

In this regard I think adding a trailing comma actually makes a ton of logical sense. Seeing [2, 3, 4,] feels like you're saying the tail element is empty, an empty list, which is exactly as I would expect.

@gnapse

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2016

I was revisiting this guide on the subject of indentation, to discuss alternatives for a project I'm working on, when I found this in the section that discourages trailing comma in method arguments:

some_method(
             size,
             count,
             color,
           )

I wonder if the evidently and unnecessarily ugly style of that method invocation is purely incidental, or intentionally used to make trailing commas look uglier than they are, in order to make their disapproval more appealing.

Why this discouraged style trait wasn't described in a more standard way, as it would be actually used by anyone in his right mind, for instance:

some_method(
  size,
  count,
  color,
)
@mvz

This comment has been minimized.

Copy link

commented Sep 13, 2016

Hi @gnapse, this ticket is about literals (arrays, hashes). This subject is inflammatory enough as it is, so can you please open a separate issue about method invocations, or perhaps a pull request to improve the indentation?

@gnapse

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2016

@mvz you're right, I was out of line here. Thanks for the suggestion, I did create the pull request (#598) with the suggested change.

@sdhull

This comment has been minimized.

Copy link

commented Oct 19, 2017

Sorry to cause notifications on an old open issue. I've skimmed this and other discussions around trailing commas in multiline literals, and come up with some pros & cons:

Pros:

  1. Aesthetics/Readability
  2. Ease of editing, particularly rearranging. Rearranging the items becomes easier because you don't have to add/remove the trailing comma. Particularly in editors like Vim where it's easy to manipulate text as lines, this is useful.
  3. Cleaner diffs, more accurate git blame
  4. Less error prone ("where'd I forget that comma?!"). One could argue this should collapse into #2 listed above.
  5. Something about it being logical for the final item in a list to be an empty list in functional languages (sorry I don't really grok this one but I also don't doubt its validity).

Cons:

  1. Aesthetics/Readability
  2. Logically the comma separates items in a list, and having a trailing comma after the last item breaks this logic, thus causing some sort of cognitive dissonance ("Separating nothing implies subtly that there is something after the last element.")

Note: I list aesthetics/readability in both because it's subjective and claimed by both people for & against.

Please vote on this post. If you are IN FAVOR OF TRAILING COMMAS IN MULTILINE LITERALS, add the thumbs up reaction. Otherwise add the thumbs down reaction.

@mvz

This comment has been minimized.

Copy link

commented Oct 19, 2017

@shull I'd like really like to vote "the guide should not make any recommendation except to be consistent within a project".

@gnapse

This comment has been minimized.

Copy link
Contributor

commented Oct 19, 2017

Ever since I found prettier in the javascript world, I stopped worrying too much about these things. I realized that people probably argue for a code style because in order to adhere to it, they need to type the code in compliance with it.

With something like prettier, you just need to type valid code in whatever style you prefer, and prettier will rewrite the parts of your code that did not adhere to its standard. And also it does not bother to give you too many configurable options, it is opinionated, and that's good, because it removes bike-shedding.

So there's two key things to it:

  1. Removes bike-shedding by offering a very opinionated code style with very little room for configuration.
  2. It automatically rewrites the code to adhere to the standard, so developers need not worry about coding with the right style while programming.

These two features have made a difference for me, to the point that I no longer mind what things of how prettier rewrites my code are different than what I would've done. It rewrites it to a very readable format anyway, and that's all that matters.

I wish there would be something like prettier for Ruby. It has changed my life regarding code styling issues.

@sdhull

This comment has been minimized.

Copy link

commented Oct 20, 2017

@mvz honestly I'm kinda with you on that 😏

@gnapse glad to hear you found a tool you like. The analog in ruby is of course rubocop but I bet you already knew that.

The problem I have with auto-formatters is they are never smart enough. They rewrite your code for the purpose of "readability", but half the time they get it wrong. For example, there's a rule in rubocop that unwinds things like !(foo && bar) to make it !foo || !bar but as recently as this past August it broke logic in some circumstances and even today, the check it does is somewhat naive, converting something like special = widgets.select {|w| w.type != 'regular} to special = widgets.reject {|w| w.type == 'regular}, which (to my mind) is less readable and more difficult to grok.

Anyway I'm glad you found one you like. Maybe one day rubocop will be good enough that I actually appreciate it.


Just re-read this thread, noting how many people actually don't like trailing commas in multiline literals. As I suspected, it's not many (2 by my count). The problem is that one of them is @bbatsov, the owner of this project. So afaict he has simply steamrolled everyone (I mean freakin @steveklabnik weighed in for trailing commas ffs).

This is a bummer because my colleague wants to treat this styleguide as a "community-consensus best practices" styleguide, but this issue in particular seems like evidence that it is more like "@bbatsov's personal preferences (maybe influenced somewhat by the community)" styleguide. Which is fine, but problematic when my colleague insists we follow it because it represents "best practices." Admittedly this is a single point, but I wonder how many others there are like it in here.

Not sure how else to interpret what's going on here.

@gnapse

This comment has been minimized.

Copy link
Contributor

commented Oct 20, 2017

@sdhull the problem with the examples you mention about the ruby code rewritter is precisely that it attempts to do too much, from what I see in those examples. prettier in js will never attempt to mess with the logic or change the AST of the code. It keeps the AST intact, just changes whitespace, indentation, etc. In my opinion, trying to enforce to that level, where a formatter thinks there's something wrong with !(a && b) versus !a || !b, it's just wrong. That's no longer a code style issue.

Also, one of the problems with rubocop that you apparently did not consider in your response, is that it allows to be configured to the lowest level of detail. And one of the main advantages of prettier in js is that it allows for very little configuration, it is opinionated, and that's a good thing, because that's where it opens the door to reduce bike-shedding in code style matters, and focus on what really matters: the code itself, and its quality beyond code style. In my opinion, as long as an automated code formatter like prettier, spits out a reasonably organized and readable code, it does not matter what precise code style guide it adheres to. The fact that it removes the burden off my shoulders to manually format the code to comply is heaven for me.

And finally, I totally agree with you that this Ruby style guide is in some degree very much about what @bbatsov prefers. It ultimately defines some of the issues.

@gnapse

This comment has been minimized.

Copy link
Contributor

commented Oct 20, 2017

BTW @sdhull, you say the analogous to prettier in the ruby world is rubocop. Is rubocop able to rewrite the code according to a set of rules? Or is it just about detecting violations of those rules, for the developer to fix?

If it can be used as a formatter, I wouldn't mind having a predefined set of rules applied (perhaps whatever rubocop has as defaults and using no config file whatsoever), and for me, that would be a good equivalent of prettier for the ruby world (provided the defaults match what's reasonably readable and organized code, which I'm sure they do).

Bottomline is, the gist for what I consider the key features for prettier's success are: opinionated set of reasonable rules with very little room for customization + automatic rewrite of code according to those rules. Those two ingredients are a recipe for success IMO.

@sdhull

This comment has been minimized.

Copy link

commented Oct 20, 2017

@gnapse

Is rubocop able to rewrite the code according to a set of rules?

Yes, it can do "some" auto-correction stuff. I couldn't find a good list of all the rules that are auto-correctable, but you may find it suites your needs (you could always leave the configuration vanilla, and/or disable enforcement of things you think are doing too much). As I mentioned, I find it obnoxious... but maybe I'll get used to it and learn to love it 🙄

@lamont-granquist

This comment has been minimized.

Copy link

commented Oct 21, 2017

I tried to have vim call rubocop -a on buffer writes and that approach introduced too much latency, and occasionally silently mangled code, it also interacted poorly with my integration with launching rspec tests from the editor, so had to remove it.

@gnapse

This comment has been minimized.

Copy link
Contributor

commented Oct 21, 2017

@sdhull good to know rubocop has some capabilities to correct files. Next time I need to work on a more regular basis on a ruby project I'll definitely research how to achieve there what I do now with prettier. I cannot stress enough how it has changed my experience with code style issues.

@lamont-granquist I'd never configure prettier to modify files on save. I have it configured to modify staged git changes on a pre-commit git hook, using lint-staged and husky. Again, these are all packages for a node ecosystem. It would be good to achieve a similar setup in a ruby/rails ecosystem using gems instead.

@lamont-granquist

This comment has been minimized.

Copy link

commented Oct 21, 2017

I currently run rubocop on a precommit hook, but again due to occasional mangling I don't want to run rubocop -a there. That means, though, that when I write code that doesn't pass validation it fails on commit and I have to fix it then recommit, which means that I generally do care that the rules match more or less what I write in order to reduce friction.

@mvz

This comment has been minimized.

Copy link

commented Oct 22, 2017

@lamont-granquist You can perhaps limit the autocorrect to only correct the offenses in the Style namespace (I haven't tried this!).

@mvz

This comment has been minimized.

Copy link

commented Oct 22, 2017

@lamont-granquist Also, it turns out:

  • You can disable autocorrect for individual cops using AutoCorrect: false
  • The RuboCop team tries to only enable safe autocorrections by default, so if you find one that is not safe, please do file a bug report.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.