i dislike the use of ‘end’ (just about the only think i don’t like in
ruby). so, since everybody is saying that this is just a matter of
taste, why won’t this work:
def fib(n)
{
if (n<2)
{
n
}
else
{
fib(n-2)+fib(n-1)
}
}
print(fib(20), “\n”);
in other words, i’m more comfortable with {} coming from C,C++, & C# so
what are the precise syntax rules for substituting {} for ‘end’? is
there anything wrong with how i structured my code above? I keep getting
syntax errors & “odd number list for Hash” errors, & i’m pretty sure it
has something to do with my syntax, since both of these work in their
original form (using ‘end’). obviously, ruby thinks i’m trying to create
a hash. so, how can i use {} instead of ‘end’ w/o confusing ruby?
i dislike the use of ‘end’ (just about the only think i don’t like in
ruby). so, since everybody is saying that this is just a matter of
taste, why won’t this work:
This is not a matter of taste, in the main.
The use of {} signifies the creation of a hash or a block, depending on
context.
What is – mostly – a matter of taste is the use of {} vs do/end in
blocks. There is a binding precedence issue.
task foo { … } # the block binds to foo, not to task.
task foo do … end # the block binds to task, not to foo.
class must be matched with end.
def must be matched with end.
case must be matched with end.
begin must be matched with end.
do must be matched with end.
Because it’s syntactically not permitted. Note that {…} can only
replace do…end.
Or what about this:
same.
in other words, i’m more comfortable with {} coming from C,C++, & C# so
what are the precise syntax rules for substituting {} for ‘end’? is
there anything wrong with how i structured my code above? I keep getting
syntax errors & “odd number list for Hash” errors, & i’m pretty sure it
has something to do with my syntax, since both of these work in their
original form (using ‘end’). obviously, ruby thinks i’m trying to create
a hash. so, how can i use {} instead of ‘end’ w/o confusing ruby?
FYI, the most often used convention is to use {} for single line
blocks and do…end for multiline blocks.
Jake McArthur
This is an oft-used convention, but it is probably wrong. I am leaning
more and more toward Jim W.'s view, where one uses do/end for
blocks that do not return a meaningful value and {} for blocks that do
return a meaningful value, and using parenthesis to ensure binding.
The only exception for this is in DSL environments where I don’t want
to expose the idiosyncratic behaviour and therefore tend to encourage
do/end only.
carlo wrote:
} i dislike the use of ‘end’ (just about the only think i don’t like
in
} ruby). so, since everybody is saying that this is just a matter of
} taste, why won’t this work:
[…]
} in other words, i’m more comfortable with {} coming from C,C++, & C#
so
} what are the precise syntax rules for substituting {} for ‘end’? is
} there anything wrong with how i structured my code above? I keep
getting
} syntax errors & “odd number list for Hash” errors, & i’m pretty sure
it
} has something to do with my syntax, since both of these work in their
} original form (using ‘end’). obviously, ruby thinks i’m trying to
create
} a hash. so, how can i use {} instead of ‘end’ w/o confusing ruby?
In general, the answers you’ve been getting are along the lines of “you
can’t do that” or “that isn’t the Ruby way” and, strictly speaking, both
are accurate. That said, there’s sort of a way to do it for methods, at
least:
class << Object
alias defm define_method
end
class Foo
defm(:bar) { |baz|
puts baz
}
end
x = Foo.new
x.bar(‘Whee!’)
So, yeah, it isn’t perfect, but if you really want that C syntax feel,
that’s about as close as you’re going to get.
FYI, the most often used convention is to use {} for single line
blocks and do…end for multiline blocks.
This is an oft-used convention, but it is probably wrong.
I wonder how a convention can be wrong. This may sound like linguistic
nitpicking, but the whole point of a convention seems to be that it’s
adhered to. It just “is” but can’t be right or wrong IMHO. There might
be more and less usable and easier and more complicate conventions -
but right or wrong?
Whoa. How about we all pretend their was an implicit “coding” in
front of the word “convention” for the last couple of posts? I think
Mr. Klemme was wondering how a coding convention can be wrong.
adhered to. It just “is” but can’t be right or wrong IMHO. There might
be more and less usable and easier and more complicate conventions -
but right or wrong?
You know Robert, I was in complete agreement with you - until
I remembered Hungarian Notation.
might
front of the word “convention” for the last couple of posts? I
think Mr. Klemme was wondering how a coding convention can be wrong.
How can a (coding) convention be wrong, instead of just less
useful, less practical?
The same argument applies to other conventions. Why is Sati wrong,
instead of just a less useful, less pleasant way to live?
Ideas have broad consequences that can’t be arbitrarily restricted:
they reach out to other fields. The full answer to the Sati case
should include whether anything is wrong at all, and whether
practical considerations have moral consequences. Those issues are
important to the question about coding.
We can even take a dialog about Sati, and then use some of the ideas
to argue about coding. Most of them will work just as well about
either topic.
Jim: “Sure, Sati sounds horrible to us, but they are accustomed to
it, and would be unhappy to live another way. It has practical
consequences, like reducing how many women are available to knit, but
wealth is only a convenience.”
Chloe: “Medical textbooks are a kind of wealth, and medicine matters.
With less knitting, they won’t be able to buy as high quality medical
books.”
So, back to coding. This medical textbook argument will work great.
Some programmers write tools for doing page layouts, and for making
diagrams. Those tools help us make better medical textbooks. The more
convenient and practical the coding conventions of the programmers,
the sooner we will have higher quality medical textbooks.
The idea that medical textbook production is a practical issue with moral consequences can be transplanted just fine between the two
cases: it has reach.
This isn’t conclusive, of course. Maybe you don’t see the moral value
in medicine. But I think it’s getting somewhere, to tie those things
together. Most of us are probably persuaded by now. And if we were to
continue on, about Sati, or coding conventions, we’d continue on in
exactly the same way – discussing medicine – because it’s all tied
to the same issue now.
i dislike the use of ‘end’ (just about the only think i don’t like in
ruby). so, since everybody is saying that this is just a matter of
taste, why won’t this work:
class Hello
{
attr_reader :msg
The point is that the {}/do/end distinction is largely (not entirely)
a matter of taste, not that you can put curly braces anywhere in Ruby
code
Or what about this:
}
}
print(fib(20), “\n”);
Don’t forget puts
puts fib(2)
in other words, i’m more comfortable with {} coming from C,C++, & C#
so
I’ve always found it’s much easier, when you’re writing Ruby code, to
“come from” Ruby. That way, you don’t have to fight the language, or
convince yourself to be disappointed because it doesn’t have the same
syntax as other languages. You free yourself to enjoy it a lot more.
Also, remember that Ruby is a language, not a vague, unformulated idea
for a language. It’s not Ruby’s responsibility to pepper the code
with curly braces because they appear a lot in C, any more than it is
C’s responsibility to stop using them because they appear less in
Ruby.
bad-hungarian is when you prefix a variable name with type information
eg:
fWidth = fSize
the ‘f’ simply means float. you can see you have type compatibilty on
both
sides, but it doesn’t say anything about semantic compatibility. fWidth
could be used as a measure in metres, whereas fSize is expressed in
feet!
good-hungarian is when you prefix a variable name with semantic
information
metric_width = feet_size
you can see immediately that there is a problem there. both variables
are
of the same type (Float), yet they have a different meaning.
I would argue that in ruby -using duck typing- we use good hungarian
quite a
lot.
you can see immediately that there is a problem there. both variables are
of the same type (Float), yet they have a different meaning.
This is a good point, but I would hesitate to call that hungarian
notation. If it looked like this:
mWidth = fSize
Where the m = “metric” and f = “feet”, then you could claim hungarian
notation. And if it did look like that, I’d campaign in favor of
expanding the prefix. Including “metric_” in the variable name isn’t
hungarian notation, it’s just a meaningful variable name, and no one
will vote against that.
I’ve always found it’s much easier, when you’re writing Ruby code, to
“come from” Ruby. That way, you don’t have to fight the language, or
convince yourself to be disappointed because it doesn’t have the same
syntax as other languages. You free yourself to enjoy it a lot more.
On Apr 30, 2006, at 5:18 PM, Elliot T. wrote:
[snip lots of interesting and good stuff]
Sorry, I reacted the way I did, cause I felt that comparison was bound to cause a horrific flamewar, and I was trying to head it off
before it started. Thankfully, I was mistaken. (Must remember the
average intelligence is higher here than Slashdot )
nitpicking, but the whole point of a convention seems to be that
Or stoning adulterers to death.
Jim: "Sure, Sati sounds horrible to us, but they are accustomed to
convenient and practical the coding conventions of the programmers,
exactly the same way – discussing medicine – because it’s all tied
to the same issue now.
Now, this has become an interesting discussion! Let’s take this a bit
further and maybe put some things into perspective.
Right or wrong can only be decided based on a set of values. We (at
least I assume you’re with me here :-)) consider Sati “wrong” because
it contradicts some fundamental value of our society (I won’t go into
the discussion of universam human rights…) - that of life itself.
Now, with software we’re far more flexible with regard to values to
base a decision on. For some it’s somehow derived from financial
values (i.e. development effort it took to code it in the first place,
cost of maintenance etc.), for some it’s more aesthetic (shortness,
symmetry etc.). I personally view it mostly from the first
perspective and to some degree from the second. Since any coding
convention (i.e. a practice that most people of a domain adhere to)
helps in understanding code it’s right from a financial point of
view.
If you try to replace an existing convention this will incur some cost
if you achieve it at all. The cost depends on the number of people
involved and the amount of software that needs to be changed to
implement the new convention (this includes development software like
IDE’s etc.). The confusion by a convention change might even cancel
out the effect of a convention at all, i.e., since there are now two
conventions none of them has the power to aid understanding etc. any
more. Just imagine what would happen in someone would try to replace
the iteration method’s name “each” with some other name.
Woa, this has become fairly theoretical. To sum it up: a bad code
convention is better than no code convention. Or put it another way:
there’s a reason why it’s so hard to get rid of conventions…
Kind regards
robert
This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.