CODEWITHSUNDEEP
ruby
gcbenison
gcbenison

Reputation: 11963

Good style for splitting lengthy expressions over lines

If the following is not the best style, what is for the equivalent expression?

if (some_really_long_expression__________ && \
    some_other_really_long_expression)

The line continuation feels ugly. But I'm having a hard time finding a better alternative.

Upvotes: 1

Views: 126

Answers (4)

Cary Swoveland
Cary Swoveland

Reputation: 110685

The following are some more-or-less random thoughts about the question of line length from someone who just plays with Ruby. Nor have I had any training as a software engineer, so consider yourself forewarned.

I find the problem of long lines is often more the number of characters than the number of operations. The former can be reduced by (drum-roll) shortening variable names and method names. The question, of course, is whether the application of a verbosity filter (aka babbling, prattling or jabbering filter) will make the code harder to comprehend. How often have you seen something fairly close to the following (without \)?

total_cuteness_rating = cats_dogs_and_pigs.map {|animal| \
  cuteness_calculation(animal)}.reduce {|cuteness_accumulator, \
  cuteness_per_animal| cuteness_accumulator + cuteness_per_animal}

Compare that with:

tot_cuteness = pets.map {|a| cuteness(a)}.reduce(&:+)

Firstly, I see no benefit of long names for local variables within a block (and rarely for local variables in a method). Here, isn't it perfectly obvious what a refers to in the calculation of tot_cuteness? How good a memory do you need to remember what a is when it is confined to a single line of code?

Secondly, whenever possible use the short form for enumerables followed by a block (e.g, reduce(&:+)). This allows us to comprehend what's going on in microseconds, here as soon as our eyes latch onto the +. Same, for .to_i, _s or _f. True, reduce {|tot, e| tot + e} isn't much longer, but we're forcing the reader's brain to decode two variables as well as the operator, when + is really all it needs.

Another way to shorten lines is to avoid long chains of operations. That comes at a cost, however. As far as I'm concerned, the longer the chain, the better. It reduces the need for temporary variables, reduces the number of lines of code and--possibly of greatest importance--allows us to read across a line, as most humans are accustomed, rather than down the page. The above line of code reads, "To calculate total cuteness, calculate each pet's cuteness rating, then sum those ratings". How could it be more clear?

When chains are particularly long, they can be written over multiple lines without using the line-continuaton character \:

array.each {|e| blah, blah, ..., blah
  .map     {|a| blah, blah, ..., blah
  .reduce  {|i|  blah, blah, ..., blah }
  }
}

That's no less clear than separate statements. I think this is frequently done in Rails.

What about the use of abbreviations? Which of the following names is most clear?

number_of_dogs
number_dogs
nbr_dogs
n_dogs

I would argue the first three are equally clear, and the last no less clear if the writer consistently prefixes variable names with n_ when that means "number of". Same for tot_, and so on. Enough.

Upvotes: 1

HM1
HM1

Reputation: 1684

Ismael answer works really well in Ruby (there may be other languages too) for 2 reasons:

  1. Ruby has very low overhead to creating methods due to lack of type definition
  2. It allows you to decouple such logic for reuse or future adaptability and testing

Another option I'll toss out is create logic equations and store the result in a variable e.g.

# this are short logic equations testing x but you can apply same for longer expressions
number_gt_5 = x > 5
number_lt_20 = x < 20
number_eq_11 = x == 11

if (number_gt_5 && number_lt_20 && !number_eq_11) 
 # do some stuff
end

Upvotes: 0

Todd A. Jacobs
Todd A. Jacobs

Reputation: 84353

The parser doesn't need the backslashes in cases where the continuation is unambiguous. For example, using Ruby 2.0:

if true &&
   true &&
   true
  puts true
end
#=> true

Upvotes: 3

Ismael
Ismael

Reputation: 16720

One approach is to encapsulate those expressions inside meaningful methods. And you might be able to break it into multiple methods that you can later reuse.

Other then that is hard to suggest anything with the little information you gave. You might be able to get rid of the if statement using command objects or something like that but I can't tell if it makes sense on your code because you didn't show it.

Upvotes: 0

Related Questions