[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.ruby

inline comments in future release?

Mike Schwab

7/24/2008 9:49:00 PM

Are inline comments a potential feature of Ruby 2.0?

Are there particular syntax or performance issues that preclude this?

With a language where so much fits into one line it could be cool to
document method calls more individually at times.

-Mike
--
Posted via http://www.ruby-....

23 Answers

ara.t.howard

7/24/2008 9:54:00 PM

0


On Jul 24, 2008, at 3:49 PM, Mike Schwab wrote:

> Are inline comments a potential feature of Ruby 2.0?
>
> Are there particular syntax or performance issues that preclude this?
>
> With a language where so much fits into one line it could be cool to
> document method calls more individually at times.
>
> -Mike



p :you # can do this....


a @ http://codeforp...
--
we can deny everything, except that we have the possibility of being
better. simply reflect on that.
h.h. the 14th dalai lama




Mike Schwab

7/24/2008 9:57:00 PM

0

ha ha sorry if I was unclear. I meant comments that can have more code
after them on the same line.
--
Posted via http://www.ruby-....

reuben doetsch

7/24/2008 10:14:00 PM

0

[Note: parts of this message were removed to make it a legal post.]

you mean like /* and */ in Java or C#. That isn't ruby and makes the code
harder to follow. Why not just comment the line above it. But do wish there
were block comments, is that in the works?

On Thu, Jul 24, 2008 at 4:57 PM, Mike Schwab <mike.schwab@gmail.com> wrote:

> ha ha sorry if I was unclear. I meant comments that can have more code
> after them on the same line.
> --
> Posted via http://www.ruby-....
>
>

Jeremy McAnally

7/24/2008 10:31:00 PM

0

BLOCK COMMENTS ARE FOR THE WEAK.

But you can do them like this if you have to...

=begin
This is my comment. Lame.
Totally lame.
=end

But I think that's sort of ugly.

--Jeremy

On Thu, Jul 24, 2008 at 5:14 PM, reuben doetsch <hjast89@gmail.com> wrote:
> you mean like /* and */ in Java or C#. That isn't ruby and makes the code
> harder to follow. Why not just comment the line above it. But do wish there
> were block comments, is that in the works?
>
> On Thu, Jul 24, 2008 at 4:57 PM, Mike Schwab <mike.schwab@gmail.com> wrote:
>
>> ha ha sorry if I was unclear. I meant comments that can have more code
>> after them on the same line.
>> --
>> Posted via http://www.ruby-....
>>
>>
>



--
http://jeremymca...
http:/...
http://omgb...

My books:
http://manning.com...
http://humblelittlerub... (FREE!)

Mike Schwab

7/24/2008 10:31:00 PM

0

fair point, it can make things hard to read if you're not careful

my main concern is that so much code goes uncommented, and the rdoc
comments being outside the body of the method contributes to an attitude
that allows this.

so many of the quality ruby libraries are so flexible and so meta that
it would be great to have more blow-by-blow explanations sometimes!
--
Posted via http://www.ruby-....

Tim Hunter

7/24/2008 10:33:00 PM

0

Mike Schwab wrote:
> Are inline comments a potential feature of Ruby 2.0?
>
> Are there particular syntax or performance issues that preclude this?
>
> With a language where so much fits into one line it could be cool to
> document method calls more individually at times.
>
> -Mike

If you have so much code on one line that you feel the need for inline
comments, you could, you know, break it up into multiple lines.

There's an old saying about C programming: Removing white space does not
make your program run faster.

--
RMagick: http://rmagick.ruby...

Tim Hunter

7/24/2008 10:37:00 PM

0

reuben doetsch wrote:
> you mean like /* and */ in Java or C#. That isn't ruby and makes the code
> harder to follow. Why not just comment the line above it. But do wish there
> were block comments, is that in the works?
>

You mean other than =begin and =end?

--
RMagick: http://rmagick.ruby...

Mike Schwab

7/25/2008 1:06:00 AM

0

> If you have so much code on one line that you feel the need for inline
> comments, you could, you know, break it up into multiple lines.

my point was about other peoples' code, including much of the stuff
written by those whose thorough style I admire. It's not that there's
too much on the lines. It's just that sometimes it would be nice to
throw an extra word or two in there. Ruby is supposed to read like
English. sometimes it would be totally appropriate to spruce up your
grammar or clarify your nouns by putting comments in between your
variables, methods, hash keys and class names.

I know that adding a crutch can have severe consequences and Matz has
made important compromises that have worked out extremely well. In fact
I think one of the most significant was his work on disambiguation that
allows us to usually forego parentheses. Writing without parens not
only makes the code more readable, it gives you natural clues about when
things are ready to go on to the next line. You basically do one thing
on each line, usually call one method on each line (and then call
methods to provide its arguments). Sometimes the line gets long, but
sometimes that's right for the situation. I feel that the more tools
you can use, the more able you are to find the right one for each
situation. Short lines are a great tool but code shouldn't be penalized
for using long, descriptive names and offering bountiful options, or for
programming functionally and with procs. I know these can all be moved
onto more lines to facilitate comments, and I do this, but how often do
you see the comments there? I tend to feel that if the trade-offs
aren't too big, we could adopt this feature and let some people try it
and others ignore it. I can only guess that it would slow down the
interpreter and therefore is an unlikely addition, but if that's not the
case maybe it's worth a second thought as you read through all the code
you see on github during the next week.

I'm reminded of one day when I suggested that it would be cool to have
highlighting that could alert you when you needed to add parentheses in
order to get the precedence you wanted. Like now, I wasn't looking for
a lecture. I was just admiring Ruby's ability to nudge you in the right
direction, and speculating about how we could maybe make it even
stronger and more accessible.
--
Posted via http://www.ruby-....

Michael W. Ryder

7/25/2008 2:09:00 AM

0

Mike Schwab wrote:
>> If you have so much code on one line that you feel the need for inline
>> comments, you could, you know, break it up into multiple lines.
>
> my point was about other peoples' code, including much of the stuff
> written by those whose thorough style I admire. It's not that there's
> too much on the lines. It's just that sometimes it would be nice to
> throw an extra word or two in there. Ruby is supposed to read like
> English. sometimes it would be totally appropriate to spruce up your
> grammar or clarify your nouns by putting comments in between your
> variables, methods, hash keys and class names.
>

The best way to provide in-line documentation is to use names that
document what you are doing. Instead of writing x += y, writing:
total_bill = total_bill + line_charge would make it far easier to find a
problem when the figures were wrong. I think it is much clearer than
using something like: x /* total bill amount */ += y /* line charge */.


> I know that adding a crutch can have severe consequences and Matz has
> made important compromises that have worked out extremely well. In fact
> I think one of the most significant was his work on disambiguation that
> allows us to usually forego parentheses. Writing without parens not
> only makes the code more readable, it gives you natural clues about when
> things are ready to go on to the next line. You basically do one thing
> on each line, usually call one method on each line (and then call
> methods to provide its arguments). Sometimes the line gets long, but
> sometimes that's right for the situation. I feel that the more tools
> you can use, the more able you are to find the right one for each
> situation. Short lines are a great tool but code shouldn't be penalized
> for using long, descriptive names and offering bountiful options, or for
> programming functionally and with procs. I know these can all be moved
> onto more lines to facilitate comments, and I do this, but how often do
> you see the comments there? I tend to feel that if the trade-offs
> aren't too big, we could adopt this feature and let some people try it
> and others ignore it. I can only guess that it would slow down the
> interpreter and therefore is an unlikely addition, but if that's not the
> case maybe it's worth a second thought as you read through all the code
> you see on github during the next week.
>
> I'm reminded of one day when I suggested that it would be cool to have
> highlighting that could alert you when you needed to add parentheses in
> order to get the precedence you wanted. Like now, I wasn't looking for
> a lecture. I was just admiring Ruby's ability to nudge you in the right
> direction, and speculating about how we could maybe make it even
> stronger and more accessible.

Peña, Botp

7/25/2008 2:44:00 AM

0

RnJvbTogTWljaGFlbCBXLiBSeWRlciBbbWFpbHRvOl9td3J5ZGVyQHdvcmxkbmV0LmF0dC5uZXRd
IA0KIyBUaGUgYmVzdCB3YXkgdG8gcHJvdmlkZSBpbi1saW5lIGRvY3VtZW50YXRpb24gaXMgdG8g
dXNlIG5hbWVzIHRoYXQgDQojIGRvY3VtZW50IHdoYXQgeW91IGFyZSBkb2luZy4gIEluc3RlYWQg
b2Ygd3JpdGluZyB4ICs9IHksIHdyaXRpbmc6IA0KIyB0b3RhbF9iaWxsID0gdG90YWxfYmlsbCAr
IGxpbmVfY2hhcmdlIHdvdWxkIG1ha2UgaXQgZmFyIA0KIyBlYXNpZXIgdG8gZmluZCBhIHByb2Js
ZW0gd2hlbiB0aGUgZmlndXJlcyB3ZXJlIHdyb25nLiAgDQoNCmluZGVlZC4NCg0Kb24gbXkgY2Fz
ZSwgaSB3YW50IHNpbXBsZSB2YXJzLCBzbywNCg0KPGNvZGU+DQoNCiMgYWRkIGxpbmUgY2hhcmdl
cyB0byB0b3RhbCB0DQp0ICs9IGMxICsgYzIgKyBtaXNjDQoNCjxvcj4NCg0KdCArPSBjMSArIGMy
ICsgbWlzYyAgIyBhZGQgbGluZSBjaGFyZ2VzIHRvIHRvdGFsIHQNCg0KPG9yPg0KDQojIHRvdGFs
IGNoYXJnZXMgdCBlcXVhbHMNCnQgKz0gYzEgKyAgIyBsaW5lIGNoYXJnZSAxIHBsdXMNCiAgICAg
YzIgKyAgIyBsaW5lIGNoYXJnZSAyIHBsdXMNCiAgICAgbWlzYyAgIyBtaXNjZWxsYW5lb3VzDQoN
CjwvY29kZT4NCg0Kbm9uZXRoZWxlc3MsIHN0eWxlIGlzIGluIHRoZSBleWUgb2YgdGhlIGJlaG9s
ZGVyIDspDQoNCiMgSSB0aGluayBpdCBpcyBtdWNoIGNsZWFyZXIgdGhhbiANCiMgdXNpbmcgc29t
ZXRoaW5nIGxpa2U6IHggLyogdG90YWwgYmlsbCBhbW91bnQgKi8gKz0geSAvKiBsaW5lIA0KIyBj
aGFyZ2UgKi8uDQoNCm91Y2gsIHRoYXQgaXMgdG9vIG11Y2guIElzIHRoYXQgYSByZWdleCBvciB3
aGF0PyA6KQ0KDQpLaW5kIHJlZ2FyZHMgLWJvdHANCg==