How can I make this if/else more succinct?

E

eggie5

How can I make this if/else more succinct?

Video.find:)all).each do |video|
if video._3gp
ext=".3gp"
elsif video._3g2
ext=".3g2"
elsif video.mp4
ext=".mp4"
end
 
E

eggie5

Actually how can this be more succinct?

Video.find:)all).each do |video|
if video._3gp ==1
ext=".3gp"
elsif video._3g2==1
ext=".3g2"
elsif video.mp4==1
ext=".mp4"
end
expected.push "#{self.id}_#{video.id}#{ext}"
end
 
L

Logan Capaldo

Actually how can this be more succinct?

Video.find:)all).each do |video|
ext = %w(_3gp _3g2 mp4).find { |m| video.send(m) == 1
}.to_s.sub(/\A_?(.+)\z/, '.\\1')
 
A

Ari Brown

Actually how can this be more succinct?

Video.find:)all).each do |video|
if video._3gp ==1
ext=".3gp"
elsif video._3g2==1
ext=".3g2"
elsif video.mp4==1
ext=".mp4"
end
expected.push "#{self.id}_#{video.id}#{ext}"
end

You can use case-when:

Video.find:)all).each do |video|
case 1
when video._3gp : ext = ".3gp"
when video._3gp2 : ext = ".3gp2"
when video.mp4 : ext = ".mp4"
end
expected.push "#{self.id}_#{video.id}#{ext}"
end


~ Ari
English is like a pseudo-random number generator - there are a
bajillion rules to it, but nobody cares.
 
D

dblack

Hi --

You can use case-when:

Video.find:)all).each do |video|
case 1
when video._3gp : ext = ".3gp"
when video._3gp2 : ext = ".3gp2"
when video.mp4 : ext = ".mp4"
end
expected.push "#{self.id}_#{video.id}#{ext}"
end

Just to streamline it a bit, you could also do:

Video.find:)all).each do |video|
ext = case 1
when video._3gp: ".3gp"
when video._3gp2: ".3gp2"
when video.mp4: ".mp4"
end
expected.push "#{self.id}_#{video.id}#{ext}"
end

Of course you could also do:

Video.find:)all).each do |video|
expected.push "#{self.id}_#{video.id}#{case 1; when .... } "
end

but that crosses over into cleverness and/or cutesiness :)


David

--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
 
J

Jacob Dunphy

It may not be more succinct, but it reads better to me.

class Video

def ext
if self._3gp ==1
".3gp"
elsif self._3g2==1
".3g2"
elsif self.mp4==1
".mp4"
end
end
end

expected = Video.find:)all).collect do |video|
"#{self.id}_#{video.id}#{video.ext}"
end
 
S

Stefan Rusterholz

eggie5 said:
How can I make this if/else more succinct?

Video.find:)all).each do |video|
if video._3gp
ext=".3gp"
elsif video._3g2
ext=".3g2"
elsif video.mp4
ext=".mp4"
end

If I see that correctly you have a database with a table with the 3
fields "_3gp", "_3g2" and "mp4".
If that's incorrect, don't bother to read on.
If it is correct: why? It seems much saner to have a field 'type' with
an enum '3gp','3g2','mp4' NOT NULL.
That way you can create your extension simply by prefixing a dot.

Regards
Stefan
 
D

dblack

Hi --

this is not meant as a flame, but this reminds me of the
"write only" code I used to see when I programmed in C.

If given the choice between the two, I would prefer the
original as it's easily comprehensible and to modify.

One of the things I like about Python and Ruby is that they
encourage/enable clean readable code, so I find the above
going against the design philosophy of the language.

Comments? Please, I am not looking for an argument here.

The original question was how to make it more succinct, not more
elegant or transparent. As it happens, I don't think there's anything
particularly unclean or unreadable about the code above, though I've
pretty much given up on "readable" as a meaningful term. All of the
copmlexity in the code comes directly from the original problem, which
requires massaging with sub for some (but not all) possible values,
and indicates the right value indirectly by having the pre-massaged
version be a method name that produces the result 1 when sent to the
video object.... Obviously it would be less cluttered if it could
just be:

expected.concat(Video.find:)all).map {|video|
"#{self.id_}#{video.id}#{video.ext}"
})

but that's not indicated by the original code.

Another point is that while Ruby certain does (in my view) provide
favorable conditions for writing nice-looking code, it's important not
to be *too* skittish about the use of constructs that can't always be
picked up at a glance. Some Ruby constructs are easier to read, and
for different people, than others. It was never part of the Ruby
contract, so to speak, that no one would have to make an effort to
learn how to read Ruby.


David

--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
 
D

dblack

Hi --

Good points .. though in general I will favor "readability" (whatever
that exactly means to everyone) over "cleverness" .. after all people
end up reading/comprehending and possibly modifying the code, so it's
good to help them as much as possible. Of course, as you say, this
doesn't mean no effort should be made to know the language and its
idiomatic expressions.

Readability is a tricky notion. I think it's most useful,
conceptually, at a pretty course-grained level. One can say that lots
of people have reacted to Ruby by finding that it is conducive to
writing readable code. That's just empirical. As soon as one starts to
get more fine-grained (such-and-such a code snippet is/isn't more
readable), the potential for disagreement rises rapidly and the
usefulness of the term starts to evaporate.

For example, people say that the /x modifier on regular expressions
make them more readable:

/ (.) ab c?
d?
(\d) /x

and all that. I find /x regexes very difficult to read and decipher
(even ones that are not parodies like mine :) That's just the way it
is. There's no point annointing any particular style (/x or non-/x) as
the "readable" one.

So it's hard even to know what will "help [maintainers] as much as
possible." This is part of why I'm so adamant about encouraging people
to stick to the traditional Ruby style, and not introduce a lot of
little idiosyncrasies just because the parser allows it. We're never
all going to agree about what's readable, and so on, but the
traditional style is what attracted most of us to Ruby in the first
place and it's as good a standard to rally around as any, and a lot
better than most.


David

--
* Books:
RAILS ROUTING (new! http://www.awprofessional.com/title/0321509242)
RUBY FOR RAILS (http://www.manning.com/black)
* Ruby/Rails training
& consulting: Ruby Power and Light, LLC (http://www.rubypal.com)
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,744
Messages
2,569,483
Members
44,901
Latest member
Noble71S45

Latest Threads

Top