Line continuation character

Help & Support
1

The crystal formatter “ignores” the line continuation character ‘\’ by deleting the end-of-line character that follows.

Personally, I find the use of this line continuation character very convenient when a line of code exceeds the standard width of the editor, and when the context hardly allows to do otherwise.

So I wonder about this choice : is it a concern of standardization or a technical reason ?

2

Do you have an example of it doing that?

I did a quick test and couldn’t replicate it:

words = "foo bar" \
        "biz baz"

puts words # => foo barbiz baz

EDIT: I mean running the formatter on this doesn’t produce any changes

3

Sure, here is an example:

def transitions
  {"abcd", 1, 42, 'A', "xyz", 3.14}
end

my_var_name1, my_var_name2, my_var_name3, my_var_name4, my_var_name5, my_var_name6 = transitions

The formatter restore the line after splitting it as shown below

my_var_name1, my_var_name2, my_var_name3, my_var_name4, \
my_var_name5, my_var_name6 = transitions

[Edit] Running the compiler on the splitted line is Ok.

4

Ahh so in actual code. Normally given the formatter actually does something already, i’d say it’s a standardization thing. I couldn’t find any previous discussion about it tho.

Is this example similar to your actual use case, or I’m assuming a contrived example just to show off the behavior?

5

No, this piece of code is taken from a real case: I simply reduced the code to the minimum and changed the variable names.
I have other examples, too.
Personally, I would think that the introduction by the programmer of a line continuation character in the source code should be respected. Hence my question!

6

In your example… Did you put the formatted code first and then the original code afterwards?

Could you post a message showing some code you have and what’s the result you get with the formatter and what did you expect to get?

7

Yeah, I think that makes sense.

8

Yes, that’s right.

Here is another example, this time unmodified, from my source code.

What I wrote and expected to be kept as is:

required_increase.times do
  narrowest_column = expandable_columns.reduce(expandable_columns.first) \
    do |narrowest, column|
    column.width <= narrowest.width ? column : narrowest
  end
  narrowest_column.width += 1
end

what the formatter rendered:

required_increase.times do
  narrowest_column = expandable_columns.reduce(expandable_columns.first) do |narrowest, column|
    column.width <= narrowest.width ? column : narrowest
  end
  narrowest_column.width += 1
end

Strangely, the code below is rendered as is by the formatter!

5.times \
   do |i|
  puts i
end
9 
5.times \
   do |i|
  puts i
end

That indentation would really bug me, like seeing a picture off-kilter on a wall. :rofl:

1 Like
10

Absolutely :smiley:

I agree with this.
I usually would tell people that long lines are a sign of an opportunity to simplify and clarify, but there are legitimate cases and it’s not generally bad.

1 Like
11

This is the formatter having fun…