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
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}"
endOn 8/24/07, eggie5 [email protected] wrote:
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’)
On Aug 24, 8:01 pm, “Logan C.” [email protected] wrote:
On 8/24/07, eggie5 [email protected] wrote:> 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’)
expected.push "#{self.id}_#{video.id}#{ext}" end
this works great, thanks.
On Aug 24, 2007, at 10:45 PM, eggie5 wrote:
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.
Hi –
On Sun, 26 Aug 2007, Ari B. wrote:
elsif video.mp4==1when 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
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
eggie5 wrote:
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
Logan C. wrote:
On 8/24/07, eggie5 [email protected] wrote:
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’)
expected.push "#{self.id}_#{video.id}#{ext}" end
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.
[email protected] wrote:
Hi –
On Mon, 27 Aug 2007, Esmail wrote:
<…>
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.
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.
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.
Esmail
Hi –
On Mon, 27 Aug 2007, Esmail wrote:
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
Thanks David, I appreciate you taking the time
to give me your informed point of view. I am
by no means an expert in Ruby (or Python) but
I do think about these issues, hence my original
question.
Esmail
Hi –
On Mon, 27 Aug 2007, Esmail wrote:
particularly unclean or unreadable about the code above, though I’ve
learn how to read Ruby.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