Crystal: Formatter option similar to vim-ruby's ruby_indent_assignment_style

[cvincent]

I originally submitted this to the vim-crystal project, and the maintainer agreed it would be a good feature, but informed me that the plugin uses Crystal's built-in formatter and so to bring the issue up here. It's fairly easy to explain:

The Ruby Vim plugin includes an option called ruby_indent_assignment_style which determines the behavior of indenting after an assignment, commonly with begin, if, etc. Two different styles are shown below, each of which is supported by this option:

@var = if some_condition
  true
else
  false
end

###

@var = if some_condition
         true
       else
         false
       end

I greatly prefer the first style, but vim-crystal only appears to support the latter style. I'd love to see this option added.

[RX14]

We shouldn't make the formatter configurable. There should be one style that crystal programs use. it complicates the formatter and creates holy wars about which style to use on a per-project basis. At least this way, we (the core team) take the flac for formatter decisions. It also reduces cognitive load for new people using the formatter. They just use the formatter and it works without configuration.

I'm sure i'm missing some points but i'm also sure we've had similar discussions before and we just don't want to have a configurable formatter.

[RX14]

BTW, my personal favourite style here is this:

if some_condition
  @var = true
else
  @var = false
end

Yes, they're exactly the same in almost all situations. Even if the variable doesn't exist. It's typed the exact same, and it's almost always cleaner. It's a bit too much of a complex transform for the formatter though.

[cvincent]

Your example is certainly reasonable for if statements. But multi-line, memoized assignments with @var ||= begin blocks are more common in the Ruby world (I know Crystal is not trying to be Ruby) and the heavy indentation is really excessive.

If the goal is avoid adding configuration to the formatter (I certainly see your points on that), maybe it's worth arguing that the default in this case should be the other style? I'm not sure many people actually like the heavy whitespace style for these assignments outside whomever originally wrote Vim's Ruby indentation script. When I Google "ruby multiline memoize", the great majority of code examples on the first page of results use the style with less whitespace.

I think you make a good case against adding configurability to the formatter, but I think it follows that those unchangeable defaults would be best based upon precedents whenever possible, especially when we have reams of past code with extremely similar syntax, written by actual people, which we can use to establish such precedents.

[asterite]

We are using this Ruby Style Guide which has 13090 stars at the moment:

# bad - pretty convoluted
kind = case year
when 1850..1889 then 'Blues'
when 1890..1909 then 'Ragtime'
when 1910..1929 then 'New Orleans Jazz'
when 1930..1939 then 'Swing'
when 1940..1950 then 'Bebop'
else 'Jazz'
end

result = if some_cond
  calc_something
else
  calc_something_else
end

# good - it's apparent what's going on
kind = case year
       when 1850..1889 then 'Blues'
       when 1890..1909 then 'Ragtime'
       when 1910..1929 then 'New Orleans Jazz'
       when 1930..1939 then 'Swing'
       when 1940..1950 then 'Bebop'
       else 'Jazz'
       end

result = if some_cond
           calc_something
         else
           calc_something_else
         end

# good (and a bit more width efficient)
kind =
  case year
  when 1850..1889 then 'Blues'
  when 1890..1909 then 'Ragtime'
  when 1910..1929 then 'New Orleans Jazz'
  when 1930..1939 then 'Swing'
  when 1940..1950 then 'Bebop'
  else 'Jazz'
  end

result =
  if some_cond
    calc_something
  else
    calc_something_else
  end

Our formatter allows both "good" styles and rejects (transforms) the "bad" styles.

[RX14]

I think this has been discussed to death, closing.

[cvincent]

@asterite That explanation addresses my concern. Maybe a standard response or a wiki page explaining the formatter's choices (no configuration/holy wars, guided by the above style guide) will help keep any future formatter requests brief if they fall outside those decisions. Sounds like a perfectly rational policy is in place.